refactor: rework wasm conditional compilation

[hugocaillard]

Context

Because it compiles to both native and wasm platform, clarinet uses conditional dependency management and compilation.
I could make dependency management mrpoe difficult than it should be

Description

Instead of managing conditional dependencies with cargo feature, we can use cargo target dependencies instead.

So instead of this

# package-a
[dependencies]
clap = { optional = true }

[features]
default = ["cli"]
cli = ["clap"]
wasm  = []

##########
#package-b
[dependencies]
package-a = { path = "../package-a", optional = true }

[features]
default = ["cli"]
cli = ["package-a/cli"]
wasm  = ["package-a/cli"]

We now do this

# package-a
[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
clap = { optional = true }

##########
#package-b
[dependencies]
package-a = { path = "../package-a" }

With this feature, we remove 100 of toml config.

Future work

The idea of simplifying this depedency management topic on the repo, is mainly to famalirise myself with it so that I can use it in stacks-core to have a clean of handling clarity-vm compilation to wasm

[codecov]

Codecov Report

Attention: Patch coverage is 15.38462% with 11 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
components/clarity-repl/src/repl/session.rs	0.00%	10 Missing ⚠️
components/clarinet-files/src/lib.rs	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[tippenein]

ah, looks like we're hitting some unreachables

[hugocaillard]

@tippenein
The unreachables were network issues in the unit tests (possibly rate limits) because some tx simulation integration tests call the hiro testnet api. (and also because it badly handles network errors)
I'll add an API key to increase the rate limit in ci