Split cosmwasm-std into 2 crates for ease of no-std and other chains support

[dzmitry-lahoda]

I am struggling with no-std support, and integration with parity substrate.

In near future we could have parity ink and solana ebf.

So most of issues arise that client messages to and from CosmWasm to be handled by host and by other non CosmWasm contracts.

So really there is no need for full CosmWasm to be no-std, but only client side.

That is serde attributes, some values like Uintu128 and Coint, *Addr, and like.

So really having just interface crate would be awesome.

[dzmitry-lahoda]

After split into cosmwasm-std and cosmwasm-core, std version can import core with std feature and reexport. That will fill retain backward compatible consumers.

[dzmitry-lahoda]

the extra complexity for contract developers who suddenly need to know from which crate to import.

People in std world will work as they did before. No changes to contract developers there.

People from no_std world will have some chance to share some code. Imagine IBC MSG sender is Solana/Polkadot.
This is not contract in no_std, but IBC sender is no_std which tries to use contract interface. So my idea to share only interface part via no_std.

core names comes from std vs core relation in rust.

[dzmitry-lahoda]

So end result more deeper integration of ibc-rs with cosmwasm and users of that in no_std environment. That is making their work easier without making std contracts writers work harder.

[chipshort]

@webmaster128 I like the idea. If we just reexport all of cosmwasm-core in cosmwasm-std, contract devs can continue to import as they do right now. Only people who need to avoid the wasm imports / exports would have to use cosmwasm-core directly.
It could also fix this issue here: #1962

[webmaster128]

Great, let's do it! I think the only slight disturbance would be how those re-exported types are presented on docs.rs. But that's not a blocker IMO.

core names comes from std vs core relation in rust.

I like, nice thinking. Much better than calling it "types" or something.

Let's start with a very minimal package to get the infrastructure in place and then move over types one-by-one.

[webmaster128]

I created #2041 for the implementation of what was discussed here. Anything else I should add to that ticket?