PHP UI for JSON Traits

[sk33z3r]

Initial UI in place where users can manually add in the trait information into a web form, instead of editing JSON directly.

Features to be implemented before merge:

• Clean up aesthetics
• Update README
• Simple instructions in the UI
• Generate config.json
• Convert RGB inputs to a color picker
• Convert filename fields to file browsers

We'll create other pull requests for future features here, like running the whole process from the UI.

[sk33z3r]

@Montspy

Note about directories:

I got rid of the example collection_name folder since the UI will handle this, and moved images to collections. I think it is more fitting to how things are structured now.
I didn't actually make this change, I thought I did.

Notes about the JSON traits output:

• The artist_address is optional. If the user doesn't input it, then I don't add it.
• background_color is a bit misleading. It's a flipped boolean, so 0 actually means YES in this case. Basically the front end is telling the backend "If the user wants a background color, start at layer00. If not, start at layer01."
• traits and variations are purely for my front-end and may not serve any purpose in python.
• I run the rarity in a simple way:

Rarity	Value
Legendary	1
Rare	2
Uncommon	3
Common	4

I think this will work properly, but perhaps we need to adjust those values.

[sk33z3r]

Couple other notes:

• I put the minter_address in the collection traits.json instead of a main config.json, because I think there will be cases where the minter/artist does not match up. It would likely be on a per collection basis, so it made sense add this in here.
• artist_name and artist_address are intended to be added to metadata files as their own fields.

[sk33z3r]

@Montspy finally remembered to put collection_lower in the json...

[sk33z3r]

@Montspy this PR is ready when you have your side sorted and confirm there are no more changes needed in PHP. I opened other tickets since I think it is in a good enough place for testers.

Before we attempt to merge, should we review and merge in #30 first?

[Montspy]

@sk33z3r I think we should merge this before #30 simply because we've both tested this branch more than #30.
In terms of merge conflicts, I don't see a big difference in the merge order between this branch and #30.

I released a new version of LooPyMinty for this branch, make sure to update your submodules!
This new release adds:

• resolve ENS, account IDs and ETH addresses for minter and royalty_address
• loads the current traits.json and config.json