fixes #850

Summary of changes

• Implement group load, display, and filtering support in Dive.
• Implement KPF group parser in TS (cli only for now)
• Implement new schema, Dive Json V2, in desktop and web, with migrations on both platforms.
• Primary key of annotation objects (trackId) is migrated to id for consistency between track and group.

Summary of Approach

The general goal in this PR is to refactor a significant chunk of the core data and logic that dealt exclusively with tracks to make generic, abstract base classes that could be extended as Track and Group variants

• track.ts becomes BaseAnnotation.
• useTrackStore becomes BaseAnnotationStore.
• useFilterControls becomes BaseFilterControls.
• useStyleManager becomes StyleManager.
• useTrackSelectionControls generally has moved into useModeManager where it seems to belong.
• TypeList becomes FilterList and takes generics.
• Lots of stuff that used to operate on Track now operates on BaseAnnotation
• FrameDataTrack, the interface to an on-screen annotation, gets expanded to include references to groups. I also back out the unnecessary "performance enhancement" of destructuring properties like confidencePairs into that interface and just pass the track reference wholesale. This performance enhancement was useless and based on an incomplete understanding of computed properties, which are always shallow refs. (They could still be watched deeply, which would be very bad for performance, but deep:true is such a red flag to me at this point that I don't see much risk in making this change -- it would be caught in review)

Instead of taking the return values of each composition function and breaking them down into reactive state and handlers, the provide interface is simplified by taking instances of the classes above (2 each, for tracks and groups).

In general, this change moves away from abusing composition functions and toward more standard OOP. Here's an example.

// Before -- Inject state directly
const allTypesRef = useAllTypes();
// After -- Inject the TrackFilter class and access its property.
const allTypesRef = useTrackFilters().allTypes;

// Before -- Inject trackMap and then fetch using helper.
const trackMap = useTrackMap();
const track = getTrack(trackMap, trackId);
// After -- call instance method on trackStore class
const track = useTrackStore().get(trackId);

This does have one glaring disadvantage: the ability to wrap functions (like removeTrack, for example) in contextual behavior (like showing a dialog) is now less obvious when and where it should be done. handler still exists, and its functions should still be used to trigger mutations. It would be great to have some way to register a chain of side-effects on certain kinds of state mutations or come up with a more sane theory of how useModeManager wraps or does not wrap mutations in other modules. Resolving this design difficulty will make a huge improvement on the quality of the code.

For now, the rule I've tried to follow is if it can be called directly (in an AnnotationStore, FilterControls, etc) do that. Otherwise, make a wrapper function in useModeManager. This is partly why I moved useTrackSelectionControls to that file.

Web notes

This change adds a new mongo collection and a migration script in docker/server_setup.py to move the old annotationItem to trackItem, change the id, regenerate indexes, etc.

Test data

I probably forgot to do some stuff IDK.

• To try the feature out, use this video https://viame.kitware.com/#/viewer/616984a677e2fb3216074bc3
• Here's a folder with annotation data: https://drive.google.com/drive/folders/1yazuOc5mwP_q98EpckEotSiHFrnz8CrO