Upgraded CosmWasm runtime in Picasso to latest dependencies

[dzmitry-lahoda]

• allowed to run parity and cosmos rust code in same wasm contract and fancy staff for precompiles
• updated host with host call depth no more cw deps reexport cosmwasm-vm#36
• removed reexport of cw std
• updated cw to version 1.2.+
• updated XCVM spec with interpetere != account, removed autogenerated obsolete ToC, made more clear impl contracts vs logic , removed mosaic died long ago
• renamed XCVM to XC as XCVM long and hard to type, and really it is more about xc/swaps/mev rather than VM, which uses some VMs
• made features, std, no_std, right as i could
• forks will be replaced by forks into composablefi under <name>-no-std later . all forks are PRs and issues on CW team repos
• unified deps into workspace deps
• started to use cw_serde fancy API to CW
• added XC to CI
• XCVM tests where failing with cargo-package-build> thread 'tests::suite::cross_chain::test_simple_crosschain_xcvm_transfer' panicked at 'Must be able which was before my commit anyway
• go over CW pallet guide - contracts work on Picasso

• PR title is my best effort to provide summary of changes and has clear text to be part of release notes
• I marked PR by misc label if it should not be in release notes
• I have linked Zenhub/Github or any other reference item if one exists
• I was clear on what type of deployment required to release my changes (node, runtime, contract, indexer, on chain operation, frontend, infrastructure) if any in PR title or description
• I waited and did best effort for pr-workflow-check / draft-release-check to finish with success(green check mark) with my changes
• I have added at least one reviewer in reviewers list
• I tagged(@) or used other form of notification of one person who I think can handle best review of this PR
• I have proved that PR has no general regressions of relevant features and processes required to release into production

[github-actions]

Picasso Preview URL

https://picasso-production-i1par7xjl-composable-finance.vercel.app

[mina86]

This should be split into multiple PRs. It’s quite hard to review as it mixes multiple changes into one. For example, XCVM → XC rename could easily be done in a separate PR. I’ve done cursory read through and so far looks good but haven’t reviewed it properly yet.

[dzmitry-lahoda]

all changes are really easy, very stupid pr just doing cargo staff, some rename and clean up. what else should i do waiting for rust to compile? )

[mina86]

Each individual change may be easy, but once you package them into a single PR they all produce big PR which is hard to read since each diff line corresponds to different thing being changed. You could have for example rename XCVM to XC, send that as a PR, and continue working on the next thing even on the same local branch.

[dzmitry-lahoda]

send that as a PR, and continue working on the next thing even on the same local branch.

as soon as somebody proves it works with rebases - sure. will do exactly that

[mina86]

as soon as somebody proves it works with rebases - sure. will do exactly that

What do you mean proves it works with rebases? I’ve been using rebases entire time I've been using git and they work great.

[dzmitry-lahoda]

What do you mean proves it works with rebases? I’ve been using rebases entire time I've been using git and they work great.

@mina86 show me you operated like you said - i would happy to follow. i have not seen you do PR, and than another PR on top of PR from same branch. like first PR into main. second PR into first PR. etc

I feel it does not work well in our context, but I may be wrong.