Introduce `ModuleAnimatedBimodalEngine`

[al2me6]

This module is a hybrid of ModuleHybridEngine and ROLDeployableEngine. It ties configs into pairs of (primary, secondary) and allows toggling only within a pair during flight. The transition can optionally be animated.

A "primary" config can declare a linked "secondary" config using the secondaryConfig key. All configs must be linked into such pairs, without any unlinked configs leftover and without any config linked to more than one other config.

The UI is modified so that only the primary configurations are selectable. To access the secondaries, a toggle button is added at the top. It also overrides the unlock logic: When unlocking or using a new primary config, the secondary will be auto-unlocked for free (since it doesn't make logical sense for the two modes to have different tech requirements, because they are the same exact engine).

An animation can be played during the transition, specified with the animationName key.

By default, the performance characteristics of the engine will be lerped smoothly during the duration of the animation, if one is defined. The lerp time can also be overridden (or set, if there is not an animation) using the thrustLerpTime key.

The names of the modes can be customized using 4 keys in MEC:

• primaryDescription and secondaryDescription: an adjective describing the two modes (ex. "retracted" and "extended").
• toPrimaryText and toSecondaryText: displayed on the mode toggle button. If these keys aren't set but the descriptions are, they will be generated as $"To {description} mode".

This PR also adds a description to the top of the selector window to clarify how each MEC variant is different.

[al2me6]

Ready for review/testing now. Some notes:

• I'm iffy about the code managing unlocks, and also have no way to test it, since I don't (yet) play RP-1.
• There's a few modifications to base MEC to allow the new module to override what it needs.
• The thrust lerping has slight issues when the throttle is reduced, but shouldn't be too noticeable/significant.
• The pairing mechanism is a little fragile for the config writer. It also places a lot of burden on the writer to ensure that the config pairs are sensible (ex. have the same cost and make physical sense), but there's not really a way to verify everything.