Fix deleting out of brackets when ghost already at end

In cases like 1+(|a+b), backspacing the open paren results in (1+|a+b),
with the cursor always next to what was the first child of the paren,
which is great. However, in cases like (|a+b), backspacing the open
paren results in (|a+b) still because there's nowhere for the ghost to
auto-expand to and then the cursor was still being inserted next to the
first child of the paren, when what we want is |(a+b) after backspacing
the open paren.
Solidify ghost if something is typed outside it

Ghosts should always be auto-expanded to the far end of the block.
Ideally you wouldn't even be able to move the cursor outside a ghost
paren, but that's impossible to do cleanly in the current architecture
(we can't just override .moveOutOf(), the cursor could end up there by
selecting the one-sided paren group and then using an arrow key to land
on either side of the, or by clicking).

However, we can still maintain the invariant that that ghosts are always
auto-expanded to the far end of the block by, whenever something is
inserted between the ghost and the end, solidfying the ghost and making
the paren pair not one-sided anymore.
Separate backspacing parens test suite #test #organization

Recommend -w to view diff.
Separate mis-matched brackets test suite #test #organization

Recommend -w to view diff.
Fix typing close bracket outside ghost paren

If you have (a+b)| and the close paren ')' is a ghost, and you typed a
close bracket ']':

Before: [(a+b)]|, with the open bracket '[' and close paren ')' both
        ghosts.

Now: (a+b]|, with no ghosts.

Recommend -w to view diff.
Reorganize Bracket's .delete{Toward,OutOf}() #reorganize

Factor out Bracket::deleteSide(), superseding Bracket::oneSideify(),
that takes care of the case of deleting the non-ghost side of a
one-sided bracket (where you want to unwrap the parens completely), and
also takes care of where the cursor should go.

This is prep for additional pairing up of one-sided brackets on deletion
(in the next commit).
Pair up opposing one-sided brackets in more cases

Specifically, the 2 cases that arise from trying to change what's
wrapped in parens by typing before deleting. For example, say we have:

  (1+2)+3+4

and we want to change that to:

  (1+2+3)+4

We can delete the close-paren, which becomes a ghost and auto-expands to
the far end, and then type a close-paren where we want to close the
paren pair. But if we instead type the close-paren first, we get:

  ((1+2)+3)+4

where the outer open-paren is a ghost. Then what if we delete the inner
close-paren? Before this commit, the inner close-paren just becomes a
ghost and auto-expands to the far end of its containing block:

  ((1+2+3))+4

where both the outer open-paren and the inner close-paren are now
ghosts, which looks clearly wrong, they clearly look like they should be
paired up.

The other case is analogous but comes from trying to shrink rather than
expand a paren pair, e.g. from:

  (1+2+3)

to:

  (1+2)+3

by way of:

  ((1+2)+3)

where the inner open-paren is a ghost.

See comments on new if-checks. Also, factor out Bracket::closeOpposing()
from Bracket::createLeftOf() and Bracket::unwrap() from
Bracket::deleteSide(), for use when dealing with these new cases.

Recommend -w to view diff.