[Proposal] Use IntFlag types for handling Strokes + cleanup

[leogott]

Currently the Stenotype class converts binary to lists of strings, but not just that -- it also stores keymap
(which is affected by the active steno system and the user configuration).
Using the Keymap (which is in essence a mutable Mapping[list[str], list[str]] without saying so) it then converts those "machine strokes" to a different list of strings, using a function called keys_to_actions.
(It also takes care of filtering out empty strokes)

This gets then passed on to an engine method (using a slightly confusing but overall sound signal/slot construct).
This method, _on_stroked, immediately converts the list[str] to plover.steno.Stroke, the class/type of which is used as a Singleton of sorts, possibly for historical reasons.
Stroke is a confusing one. It is a subclass of int (good!), has like three methods of its own, but also a helper class, written in C, that it defers to for almost everything (30 methods or so).
(Idk why it doesn't inherit from it using multiple inheritance, but maybe there's a quirk with the mro that I'm not seeing)

This stroke class it what eventually arrives at the Translator class' translate_stroke method, just to be immediately packed into a more opaque Translation object, where it's usually in the presence of several friends as an outline.

Then there is plover.system, module acting as a Singleton storing the active steno system. Except -- there appears to be no reason for it to be one. It is barely ever accessed, and only has a method to replace all of its data.

I propose the following changes:

Instances of plover.machine.base.StenotypeBase (eg. plover.machine.geminipr.GeminiPr)
should emit Instances of IntFlag instead of list[str].

The StenotypeBase instance should not be keeping track of the keymap. Instead the Keymap should either be handled by the Engine Instance entirely, or handled in the Stroke.from_keys method and stored in a class attribute there.

The steno.Stroke class should subclass enum.IntFlag. Whenever Stroke.setup was called before, instead the reference to Stroke should be dropped, and a new Type created from Stroke (happens all tidy and behind the scenes with enum).

Accordingly, the Keymap should be a Mapping from a machine-specific IntFlag type to a system-specific IntFlag type.

plover.system.setup should define a method for loading a system from the registry into a dataclass, probably store a reference to it for reuse. Engine will store a reference to this class representing the active system.
plover.system should also define a method for getting the Stroke type specific to a system (maybe don't call it get_stroke). The stroke type could come with a reference to the system dataclass.
Or this method could belong to a system class.

Additionally to the Stroke class, there should be an Outline class, a thin wrapper around Tuple[Stroke] and this should be used whenever strokes are joined in a tuple now. (The Translation class should then store Stroke instances, mostly.)

Why?

Storing and operating on lists of strings, devoid of context, is inefficient and an inaccurate data model. It's also confusing from a new plugin developer's perspective.

Why not?

• It might be more work than I do on my own right now. I started on it already so I'm hoping for your feedback.
• Maintaining backwards compatibility might reduce the positive impact.
• Apart from that, I'm asking you.