Impacts of Client/Guest Split on Dances Zome

[evomimic]

Background

The focus of Discussion #198 was on splitting the holon_zomes functionality into client-specific, guest-specific, and shared crates. Implementation of the changes in the enhancements the emerged from that and related discussions has a ripple effect on the dances zome.

Core Logic -- The following are required on both the client and guest sides:

- DanceRequest and DanceResponse objects

Guest-Specifc -- the following are required ONLY on the guest-side

- dance executors (i.e., the `xxx_dance` functions defined in `holon_dance_adapter` and `descriptor_dance_adapter`)

Client-Specific -- The following are required are required on the client-side:

- holons dance builders (i.e., the `build_xxx_dance_request` functions defined in `holon_dance_adapter`) are  required by `holons_client`.
- descriptor dance builders (i.e., the `build_xxx_dance_request` functions defined in `descriptor_dance_adapter`) need only reside on the client-side, but they are not required `holons_client`.

NOTE: SessionState and StagingArea are being retired by Issue #202 and are out-of-scope for this enhancement

Proposal

1. Move DanceRequest and DanceResponse to a new dances_core crate within crates.
2. Move Dancer into a new dances_guest crate within crates.
3. Adjust the dances zome's Cargo.toml so it just includes dances_core and dances_guest crates.
4. Migrate the 'build_xxx_dance_requestfunctions inholon_dance_adapter into a newholon_dance_builders crate (descriptor_dance_adapter` will be addressed later).

These and other changes are being implemented via enhancement #206 .