Refactor/lib restructure

[boyswan]

No description provided.

[Maar-io]

name example/simple is misleading. This is the most complex example with all crates included

[Maar-io]

Can you make it so that example imports crates it need to use. Now in example contract the rmrk crate is included which then includes all other.
Perhaps creating one more example with only minting and nesting will show the best way to do that.

[boyswan]

Can you make it so that example imports crates it need to use. Now in example contract the rmrk crate is included which then includes all other. Perhaps creating one more example with only minting and nesting will show the best way to do that.

IMO it's better to keep to a single entry crate (much like ink! and openbrush) rather than users having to depend on crates individually. Maybe we could put crates behind features flags so users only pull in the sub-crates they need?

We could have something along the lines of:

rmrk = { path = "..", default-features = false, features = ["nesting", "minting", "base", "equippable", "multiasset"] }

Maybe it makes more sense to decide what logical groups of crates are actual features (ie. equippable actually depends on multiasset and nesting). Such as:

default = ["common", "minting"] 
equippable  = ["nesting", "equippable", "multiasset"] 
# etc...

[PierreOssun]

@boyswan agree. Let's create features with logical group of crate as you mentioned and keep a single entry crate

[PierreOssun]

LGTM