Consider changing StatesDesired to use State<Logical, Physical>

[azriel91]

Currently:

• StatesDesired is conceptually a Map<ItemSpecId, StateLogical>.
• StatesCurrent is conceptually a Map<ItemSpecId, State<StateLogical, StatePhysical>>.

The original rationale for this design is to model logical state as something a consumer / user can define or declare, whereas physical state is computed and cannot be known until actual execution.

The downsides to this approach are:

• Not simple to visually compare both states_current.yaml and states_desired.yaml.

• The shape of state comparisons cannot be treated uniformly.

  Difference between states.get::<State<StateLogical, StatePhysical>, _> and states_desired.get::<StateLogical, _>:

  let states = resources.borrow::<StatesCurrent>();
  let state = states.get::<State<StateLogical, StatePhysical>, _>(&item_spec_id);
  let states_desired = resources.borrow::<StatesDesired>();
  let state_desired = states_desired.get::<StateLogical, _>(&item_spec_id);

This has caused at least one mix up where I tried to retrieve a StateLogical from StatesPrevious, where I should've been requesting a State<StateLogical, StatePhysical>.

---

Part of fixing this:

• Update docs to indicate that StatesSaved is strictly speaking the re-read values from states_current.yaml which may have gone out of date
• Ensure that StatesCurrent is present iff the current states were discovered in the exact current execution. Change StatesCurrentReadCmd to StatesPreviousReadCmd.
• StatesDeserializer should be refactored to deserialize StatesSaved and StatesDesired.
• peace::rt_model_*::Error should use a common variant for States*Deserialize and States*Serialize.