(A similar fix should be done for custom procedure positioning later.)

I'm disappointed that this CSS ever worked

I'm not sure why I thought the sprite highlight box extended outside the
stage

The Stage component will sometimes have a color picker background,
which darkens the entire screen when the color picker loupe is active.
This color picker background element should appear in the same level as
the stage's wrapper, not inside of it. Previously, this was done by
wrapping both the stage's wrapper and color picker background in a div.
Now, they're both wrapped in a React.Fragment to avoid a completely
unnecessary div wrapper.

This makes the layout behavior for stage overlays much more consistent.

Items whose overflow *should* be contained within the stage, like the
monitors and color picker loupe, are now placed within the "stage"
element directly.

Items whose overflow should *not* be contained within the stage, like
the target highlight box and dragged sprite, are now inside a "stage
overlays" container element, which is properly positioned (taking into
account the stage's border width) and sized.

This is made possible by unifying stage layout across both fullscreen &
non-fullscreen modes via moving the fullscreen overlay styles to the
StageWrapper component. Whereas previously, the stage overlays were
positioned *outside* of the stage in fullscreen and had to reposition
themselves correctly, they are now positioned the same in both
fullscreen and regular modes.

The stage + target pane wrapper's width must be constrained to that of
the stage, even when there are lots of sprite tiles. Otherwise, once you
add enough sprites, it'll grow horizontally past the stage size. The old
code set its maximum width explicitly to stop that from happening, but
it can also be done more elegantly with the flex-basis property.
This also has the benefit of taking the stage border width into account.

Since #3885, the GreenFlagOverlay has been hidden by the Stage component
instead of having to hide itself if the project has been started. Thus
there's no need for GreenFlagOverlay to know whether the project has
been started.