Include muscle activation dynamics in the AbstractMuscle, not the AbstractPlant instance

[mlprt]

See #29 for an review of the structure of AbstractPlant, and how dynamical updates are aggregated. I'll try to summarize the relevant aspects, here.

MuscledArm has a field activator, which is an AbstractDynamicalSystem that describes how a muscle's activation changes with its input. For example, we could use a first-order filter to smooth out the input to the muscle, as an approximation of the dynamic of calcium diffusion through a muscle fibre in response to activity at a neuromuscular junction.

The activator component is included in the dynamics_spec of MuscledArm, which is a subclass AbstractPlant; all the components defined in dynamics_spec are automatically aggregated into a single vector_field method that is used as the ODETerm to a Diffrax solver.

Conceptually, it makes more sense for the muscle activation dynamics to be part of the muscle model -- i.e. AbstractMuscle. However, AbstractMuscle is only a subclass of AbstractStagedModel, and only defines a sequence of kinematic updates, and no vector fields.

To fix this, I think AbstractMuscle will have to subclass AbstractDynamicalSystem as well as AbstractStagedModel, similarly to the inheritance pattern already used by AbstractPlant.

This should reduce confusion between "muscle input" and "muscle activation". According to the above description, it's activation that's passed as the input argument to an AbstractMuscle. In some cases however, we might omit the activation filter, and pass a neural network's output directly through AbstractPlant, to AbstractMuscle.