Incompatible crates prevents extensive testing

[zie1ony]

For Odra developers moving from 1.5 to 2.0 should be smooth process. We already developed integration with new EE crates. Now we are focusing on how testing how smart contracts goes through the upgrade. We already have developed 2.0 integration on a separate branch feature/casper-2.0. Yet it's not very handy to work with both 1.5 and 2.0 when testing migration via switching branches. We can do much better. We could allow developers to specify the correct target via CLI flag --condor. Eg. building wasms would be cargo odra build --condor.

To do that in Odra, we can introduce new Rust feature condor, that would switch underlaying crates to 2.0. Like this:

[dependencies]
casper-execution-engine = { version = "7.0.1", optional = true }
casper-execution-engine-condor = { package = "casper-execution-engine", git = "https://github.com/casper-network/casper-node.git", branch = "feat-2.0", optional = true }

[features]
default = ["old"]
old = ["casper-execution-engine"]
condor = ["casper-execution-engine-condor"]

Unfortunately this is not possible due to "too restrictive" dependencies. Above gives this error:

error: failed to select a version for `schemars`.
    ... required by package `casper-execution-engine v7.0.1 (https://github.com/casper-network/casper-node.git?branch=feat-2.0#ee9c6de3)`
    ... which satisfies git dependency `casper-execution-engine-condor` of package `deps-test v0.1.0 (/Users/ziel/workspace/odra/deps-test)`
versions that meet the requirements `^0.8.16` are: 0.8.21, 0.8.20, 0.8.19, 0.8.18, 0.8.17, 0.8.16

all possible versions conflict with previously selected packages.

  previously selected package `schemars v0.8.5`
    ... which satisfies dependency `schemars = "=0.8.5"` (locked to 0.8.5) of package `casper-execution-engine v7.0.1`
    ... which satisfies dependency `casper-execution-engine = "^7.0.1"` (locked to 7.0.1) of package `deps-test v0.1.0 (/Users/ziel/workspace/odra/deps-test)`

failed to select a version for `schemars` which could resolve this conflict

I propose to make it possible to include old and new crates in the same project. Crates that need to work:

• casper-execution-engine
• casper-types
• casper-contract
• casper-hashing
• casper-engine-test-support

This way we will be able to provide much better 2.0 support and potentially detect errors.

[zie1ony]

Example repo: https://github.com/zie1ony/cspr-deps-clash