ci: add component contract check

[erwanor]

This add a quick cargo check to avoid leaking platform specific dependencies in our workspace, and breaking downstream dependencies like the wasm crate used by the extension.

The script itself could be refactored into a one-liner, but the current structure makes it easy to observe which crate fails to build for the special target.

[jessepinho]

Nice, thanks for this!

[conorsch]

This CI check runs with --no-default-features. That's a nice start, but over in the web repo, some crates do use the default features to in order to compile: https://github.com/penumbra-zone/web/blob/d7d46634faae608928fb696c6ae276e06dc1aa09/packages/wasm/crate/Cargo.toml#L17-L32

Therefore I think the sanest strategy we can have to prevent breakage is:

1. clone web from its main
2. patch its wasm cargo.toml to use a path dep on a local checkout of the monorepo feature branch being tested
3. ensure the web's wasm crate builds with those path modifications

Anything else is prone to breakage without us noticing. I'll pop into web sync tomorrow to ask for more detail; I know you and @jessepinho already spoke a lot about this!

[erwanor]

Respectfully disagree, we should have a check that our core crates, in particular the core/component ones, always honor the component feature contract. This contract consists in gating the complicated platform-specific logic behind a special feature (component), and allow downstreams to import basic data structures modeling the protocol (e.g. penumbra_stake::UnbondingToken). We should do this for all the relevant crates, even if they're not currently used by the wasm planner (e.g. penumbra-funding or penumbra-governance).

The wasm crate is the primary consumer of the penumbra core crates, but there could be many more and we want to allow tooling to be possible to build by default.

There are two crates that the wasm crate import with default-features = true it's true, but they're basic structure crates (e.g. penumbra-num) and should be platform-agnostic almost definitionally.

[conorsch]

Discussed this OOB with @erwanor, and we're both happy with the changes here.