Restructure how the Motion Tree gets parsed

[trystyncote]

I'd like to (finally) get to work on restructuring the frame-drawing functionality (compile_video()) to make it compatible with detecting for qualms objects, but I noticed that the functionality comes with some reworking debt that I'd like to explore for my benefit.

Most notably, I'd like to allow more context to be properly derived from the MotionTree structure. To explain what I mean, I'd like to demonstrate the pseudo-code of what it is currently doing.

for every node in the parsed motion tree:
    if the type of the node is "Start":
        - draw the first frame
    if the type of the node is "HideImage", "MoveImage", or "ShowImage":
        - check if we already drew the relevant frame
        - if not, draw the relevant frame
    if the type of the node is "InvokePrevious":
        - draw multiple frames, starting from the current index, and count up to the node's "length" value
    if the type of the node is "Continue":
        - add the node's "length" value to the current index
    if the type of the node is "End":
        - break the loop

Putting aside the HideImage, MoveImage, and ShowImage node types that could really just be InvokeAdjustment or the like, I'd like to point out that not a lot of context is properly derived. "Drawing the frame" in the current code is to create a FrameInfo instance that's later passed through the frame-drawing logic (part of the changes to the core functionality I want to work on).

I'd like to derive context better. For example, Start could store a list of IDs pertaining to all of the ImageReferences that are visible from the start of the video (frame index 0), and every HideImage, MoveImage, and ShowImage node could update this starting list of "relevant references".

I think each node is relatively well-purposed. Here's what I think:

• MotionTree - represents the outermost node, meant to contain sub-elements within its body.
• Start - represents the starting conditions, and demonstrates that the Motion Tree has sub-elements.
• End - represents the conclusion to a video; I think that if a "true video length" is every derived, or a limit on length is put in place, this represents a "hard stop" to the duration of the video.
• Continue - represents a length of frame indexes where no change occurs; following "frame caching" rules, these frames do not need to be redrawn, and can be delegated to the internal function _fill_undrawn_frames().
• InvokePrevious - represents no new instruction, but the frame has a change that's still be invoke -- such as via a MoveAdjustment, and the new frame needs to be drawn.
• HideImage/MoveImage/ShowImage - represents the invoking of an Adjustment-like object.

Here are the changes that I think should be put in place. Unmentioned nodes will not change.

• Start - include a list of "relevant references", which will currently be all ImageReference objects that are not hidden (i.e. has the visibility property as VisibilityStatus.HIDE).
• a new node type, MultipleChanges, which will store multiple HideImage/MoveImage/ShowImage nodes that represent the same index. This means we don't have to check for previous activations that parallel the current frame, and do not require that we wait until further context is known to try and draw the frame.
• End -- only if a true "video length" is devised. If the user decides to cut the video in half, then End could include the "relevant references", and even InvokePrevious-adjacent context, that could act as future starting context.
• HideImage/MoveImage/ShowImage - all of this should combined into be ActivateAdjustment, but Adjustment objects would need an ID independent of its corresponding ImageReference object.