Jungfrau rotation plan refactor plan

Below will be a list of things which should go into i24's jungfrau rotation plan, but didn't make it into the initial version for time reasons. Once the list is addressed, the i24's rotation plan should be be combined with Hyperion's rotation plan as much as possible, so that we have a new common rotation plan

- Rethink parameter model for rotation scans. i24 often want to specify a list of transmission fractions to trigger successive plans. I can't really think of a nice way to do this within the parameter model. Simplest, but not clean solution, was to just ignore the `transmission_frac` field which we get from `DiffractionExperiment` and define a new `transmission_fracs` which is used instead

- Do https://github.com/DiamondLightSource/mx-bluesky/issues/1224
- Refactor the zebra mappings so that you are allowed to choose which detector is being used (this needs to be somewhat addressed before the rotation scans can be merged at all): https://github.com/DiamondLightSource/mx-bluesky/pull/1316
- Create a common composite protocol for "essential rotation devices"
- We should separate tidy up plans for the single rotation plan VS the multi-rotation: What needs to be cleaned up in between rotations during the multi rotation scan, and what needs to be cleaned up after everything has finished?