Create cosmwasm-core crate

[aumetra]

Closes #2041

Rough draft for now. Some uglypoints, such as the weird __internal module definitely need bikeshedding.

TODO:

• Align version between cosmwasm-core and cosmwasm-std
• Add CI tests for cosmwasm-core, including no_std tests
• Add cosmwasm-core to table of crates in repo root README.md
• Move types
  • Binary
  • HexBinary
  • Addr
  • CanonicalAddr
  • Uint*/Int*
• Make base64/hex encoders/decoders public (see Implement From<&Vec> for Binary and HexBinary #2036 (review))?

[aumetra]

The build for no_std fails because of the forward_ref crate (see jtempest/forward_ref#2)
Funnily enough the linked PR was originally made because of a precursor of this change.

We can either:

• get rid of it and manually roll the impls
• vendor the macros
• fork and maintain it ourselves

I'm guessing there's not a lot to maintain since the crate just copied internal macros from the STL

[webmaster128]

• get rid of it and manually roll the impls

I would prefer that approach as it allows us to ensure the implementation serves our often-not-trivial needs. If you look at packages/std/src/forward_ref.rs we already have a place where those things can go.

[aumetra]

For some reason the derivative crate just didn't want to cooperate? (some weird compile errors complaining about modules not being found in core while they are clearly available there)
So I simply replaced them with derive_more which is already used in the core crate to provide the thiserror-like From and Display impls.

And it's one less dependency with the syn v1 requirement.

[aumetra]

Last bit of bikeshedding: Do we want to remove the error cases of things that aren't handled in std anymore?
Right now I kept them due to semver compatibility. But that is kinda broken anyway since there was no #[non_exhaustive] annotation above the error, meaning a new case is technically semver breaking since it breaks exhaustive matches.

Well, I would just go ahead and keep them since exhaustive matches are a niche usecase but removing cases could have major implications.

[webmaster128]

Nice work!

My main worry here is that looking at a bunch of details we can't easily hide away the extra crate from the contract developer, which means more comlpexity to handle for them. Not sure if there is anything we can do to improve the situation.

[aumetra]

Looking at the codecov diff, it seems like the difference mostly stems from the fact that the schemars derive has to be gated behind the std feature in a separate line.
Since most of the JSON Schema doesn't really have tests, the coverage misses add up (+0.10-0.20% per file which had to be modified)

[aumetra]

For what it's worth, I think snapshot testing for the JSON schema is worthwhile, but IMO outside the scope of this PR.

[chipshort]

Nice work!

[aumetra]

God, that rebase was something..

[aumetra]

Oh good, the commit finally made it. GitHub really crashed for a bit there, huh?