Progress moves as their own Item type

[rsek]

I've been thinking on ways to make the progress subtypes more flexible/extensible. The conclusion I keep coming back to is: maybe progress moves ought to be their own Item type.

Okay, maybe that sounds a little extreme. But hear me out! My reasoning goes like this:

1. Progress track subtypes, as written, are really a function of available moves that make progress rolls. in other words, progress track subtypes are 1:1 with the progress moves associated with them. (the exception is legacy tracks and the classic bonds track, but they'd need their own specialized handling no matter what we do).
2. We use the subtype property for two things: providing a label like "Vow" or "Connection"; and determining which move text to provide (currently just for vows, but it'd be cool to expand that behaviour).
3. Instead of having a static set of progress subtypes, we could address progress subtypes programmatically by embedding that data in the associated move item.
4. Progress moves already have a bunch of options/features that are mutually exclusive with non-progress moves. Now that we're using the data model, the features common to all moves could be represented with an abstract class, MoveBase, to keep it DRY; then Move and ProgressMove can extend that.
5. Progress track items could reference a progress move by ID . With a ForeignDocumentField, the stored ID would become a reference to that item at run time.

With that in place, several things become simpler:

• adding a new progress subtype happens automatically when a new progress move is added
• distinguishing progress moves from other moves
• progress subtypes are localizable with the rest of the move
• want to roll a progress move from the move rather than finding a track? no problem -- filter all available progress items that reference the progress move, and provide them in e.g. a dropdown

Required changes

Data migration

• for progress track items: look at the subtype property, infer the relevant progress move, and insert the move's ID; fall back to null for generic 'progress'-subtyped tracks
• for moves: test if it's a progress move; if yes, pass to the progress_move model. otherwise, pass to the move model.
  • if it has both action rolls and progress rolls attached to it: generate both a progress_move and a move to preserve the data, and inform the user of it

Progress track components

• provide a new subtype label string pointer
• editor: generate a dropdown menu of available progress moves + progress type labels. the pack index can provide enough data to do this without fully loading every move

Move components

• many components would be the same; the main thing would be restricting certain action choices depending on move type

Roll pipeline

• typings, mostly; some stuff will just get an IronswornItem<'progress_move'> instead. There's specific methods for progress moves anyways, so this won't change much