This is a breaking API change that changes handleEditorEvent to take
BrickEvents instead of Events. This paves the way for handling Brick's
mouse events in the editor.
The BorderMap module provides a notion of an empty map. Previously, this
was accidentally conflating two kinds of emptiness: an map that doesn't
track points, and a map that tracks a point (or multiple points) but
doesn't associate it with anything. This meant that the empty map was
not a unit for the union operation, which seems like a natural
expectation.
This has been resolved by revising the empty map to be the one that
tracks no points. Callers that expected that behavior were left alone,
while callers that expected the other behavior were fixed to use
`emptyCoordinates`.
This change makes it so that when cells are empty (have zero width and
height) and are top- and left-aligned, we pad them to take up the same
amount of width and height as their row- and column-wise neighbors. This
was already the case for other alignment settings, but the top- and
left-aligned cases were not getting padded.
This change fixes a bug that surfaces when an extent has been moved
partially "off screen." This can happen if an extent is translated so
that its left or top edges are outside of the rendered image. Prior to
this change, such extents would get cropped so that their upper-left
corners were always clamped to (0,0). This was wrong because it
fundamentally broke the extents' coorinate system. This change not only
preserves upper-left corner coordinates but also updates the width and
height calculations in extent-cropping to ensure that the new width and
height values still reflect the true "width" and "height" of an extent
even if some of that width or height is not visible in a rendered image.
This is essential for ensuring that mouse click detection works as
needed to translate screen-space coordinates of mouse clicks into local
(extent) coordinates for extent-matching purposes.
