dsl for behaviours for characteristics

[matt-beanland]

The structure fields define what may exist.
The behaviour fields define how they behave. Defaults, liveness etc belong here, and would generally be related to actions.

For characteristics we may want to add/remove/update them, and add/remove/update their values.
For features we may want to add/remove/update them, and update their values, including feature characteristics just like characteristics.
For parties we may want to relate/unrelate them, or change their role.

For updating characteristic values we may want to set or unset a field within a value. This could just be the primitive, or could be field/s within the dynamic. We might want the value to be the result of a calculation (at that time). This is liveness with memory, so needs to be in a create/update.

If we did this in a read action we get liveness without memory. I'm not sure we need that.

This card is just to do characteristics, and may conclude with writing cards for features and parties. We could also imagine characteristics behaviour where fields are updated regularly, for instance aggregates.

[matt-beanland]

Now we've consolidated the provider DSL #103 and have party and place extensions, it may actually make sense for there to be a base fragment characteristic, and extend characteristic in order to lever ash fields directly on them, such as expressions, and not have to use Ash.Type.Dynamic unless we really want to. This will change the provider DSL on the instance, since we'll be talking about which characteristic resource we use rather than the type of the value. It will also impact the assigner, which we intent to refactor. We'll also want to do something similar for Feature.