Move types to *_model and *_rt_model crate structure

[azriel91]

The early way types were organized is (for example):

• peace_cfg: types and traits needed to define Items,
• peace_rt_model{_core}: types and traits needed to run at runtime

That kind of organisation means different logical concepts are grouped together in one crate,
i.e. since Item needs to know about:

• States (container for different items' states) and
• Progress (for sending updates)

those get lumped together.

To be resilient to the "catch all" crate, it is beneficial to split the crates up into peace_flow_model, peace_flow_rt_model, peace_state_model etcetera, so that types are grouped by their concept rather than their usage.

Crate types

<concept>_model crates

All <concept>_model crates will have types that are:

• For the most part, pure data.
• PartialEq and Eq as much as possible.
• Serializable / Deserializable so they can be stored and re-presented across different executions.
• Presentable as much as possible -- so what is stored can be presented in different OutputWrites.

<concept>Error types should:

• live in these crates, as we want to store and re-present them later.
• be named <TheConcept>Error, so that when importing multiple error types, we don't need to alias them in the import.

<concept>_rt_model crates

These crates should contain data types that may not be serializable, e.g. ParamsSpec may contain a mapping function, and the logic cannot be serialized (#156 is related, we may revisit if we want to support storing mapping functions, and executing later).

<concept> crates

Maybe these should re-export the lower level crates.

This is certainly needed for the webi output / components, since webi_output must only be enabled for an ssr build, and webi_components enabled for both ssr and csr.

Backward Compatibility

One way to remain backward compatible / discovery friendly is, the peace_cfg crate could re-export all the different types that are used together. Not sure how this would look like, if it were to be done.

Candidates

• peace_params: Move ValueResolution* types to peace_params_model -- so we can serialize it, easier for troubleshooting.
• peace_cfg: Remove State.
• peace_core:
  • Move ItemId, FlowId, Flow into peace_flow_model maybe.
  • Move Progress* into peace_progress_model.
  • Should Item be called ItemSpec once again? Because we need to represent it in both the "what the item is specified to do", and "what values it held during this execution".
• peace_resources: Move States* into peace_states_model maybe. May keep this crate as special.
• peace_rt: Rename to peace_cmds?

[azriel91]

Worked on renaming Item to Step in #192, but wording of things didn't flow as well:

1. "Item state", current state of an item, flow better than "step state", current state of a step.
2. There was improvement in wording for "a process is made up of steps" than "items", and "this step runs before the next step".
3. Splitting a Step trait from the Item trait may be an option / something to encapsulate what would run in a CmdExecution, if necessary.

See the PR for a nushell script for the renaming.