Half the reason we swapped the render queue / settings parent relationship was
so we don't need to go through the settings screen to access the queue. But for
some reason I stopped half way through and didn't also move the "You need at
last two keyframes." popup. This commit rectifies that.
That is, most of the business code should not be aware that it is being compiled
to multiple versions even when it heavily interacts with MC, preprocessor
statements should be an escape hatch, not the norm.
Similarly, code should not be forced to do `MCVer.getWindow(mc)` instead of the
much more intuitive `mc.getWindow()`, and a new preprocessor (technically remap)
feature makes this possible by defining "search and replace"-like patterns (but
smarter in that they are type-aware) in one or more central places (the
"Patterns.java" files) which then are applied all over the code base.
In a way, this is another step in the automatic back-porting process where
preprocessor statements are used when we cannot yet do something automatically.
Previously we "merely" automatically converted between different mapping, this
new feature now also allows us to automatically perform simple refactoring
tasks like changing field access to a getter+setter (e.g. `mc.getWindow()`), or
changing how a method is called (e.g. `BufferBuilder.begin`), or changing a
method call chain (e.g. `dispatcher.camera.getYaw()`), or most other
search-and-replace-like changes and any combination of those.
The only major limitation is that the replacement itself is not smart, so
arguments must be kept in same order (or be temporarily assigned to local
variables which then can be used in any order).
Previously you'd access the render queue from the render settings screen which
was arguably the wrong way around (e.g. you weren't able to access the queue
when your current keyframes were incorrect even if you only wanted to render
those in the queue).
Now the render button opens the queue which can open a new settings popup. To
save people who don't need the queue from always having to go through it, the
queue will immediately open a new settings popup if does not yet have any jobs.
Failure to load the entity tracker usually (not always) results in
`entityTracker` remaining to be `null`, so there has to be an additional
condition for aborting the thenRun-loadEntityTracker-…-recursion.
The failing entity tracker really only breaks spectator keyframes.
This is also very desirable for minimal mode where entity tracker
failure is highly likely.
