change: Rearrange crates by feature

[AmbientTea]

Description

This is a starting point for a discussion on how to better structure our code, keeping in mind that:

• we want to de-focus the demo node/runtime in how we think about our code
• we want to focus instead on our offering being a loosely-coupled, modular features
• we adopted from Substrate some of their conventions, in particular their strict division of "pallet" and "primitive" crates, but for us a domain partitioning of the code would possibly make more sense (imo).

This PR groups the crates mostly by-feature (where "feature" in some cases means whatever grouping I came up with really), with some supporting crates and executables living in separate folders. The idea is that we want to better control cross-feature dependencies.

The grouping is as follows:

• utils - self-explanatory
• substrate-extensions - all the crates that we copied and modified from Susbtrate
• sidechain - a "core" sidechain "feature": the domain crate, sidechain-pallet and the mc-hash functionality. I imagine this being the base feature that makes a Substrate chain a Cardano "sidechain", by referencing a genesis UTXO, dividing up slots into sidechain epochs and referencing MC blocks in header
• committee-selection - selection, authority-selection-inherents and session-validator-management crates. This is the feature that builds on the "sidechain" feature by tying committee selection to data observable on Cardano
• block-production-log and block-participation - I'm tempted to group those into one "feature" that builds on committee-selection by tracking the block production
• address-associations - this builds on "sidechain" feature, by introducing an ability to tie your identity on Cardano to that on a Partner Chain
• native-token-management - self-explanatory
• smart-contracts - plutus-data, offchain and commands
• mainchain-follower - no changes here, it uses types from smart-contracts to provide data to all the features above that use observability
• cli - all CLIs that go directly into the node, including the wizard

This is following this attempted division of our system into modular "features":

Checklist

• Commit sequence broadly makes sense and commits have useful messages.
• The size limit of 400 LOC isn't needlessly exceeded
• The PR refers to a JIRA ticket (if one exists)
• New tests are added if needed and existing tests are updated.
• Relevant logging and metrics added
• Any changes are noted in the changelog.md for affected crate
• Self-reviewed the diff