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.
Fix edge case where ghost might not be at end

As you can see in the test case, the edge case is if you have:

    1+((2+3))

where the inner open-paren is a ghost, and you delete the outer
open-paren, which becomes a ghost and auto-expands to the far left end:

    (1+(2+3))

Before, the inner open-paren would remain a ghost, just hanging out, not
at the end of its block. Now, we call .siblingCreated() on the inner
open-paren to solidify it.

Note that there's no need for a symmetric call to origEnd's new sibling
because it gets .siblingDeleted() called on it by Controller::deleteDir
(in keystrokes.js).

(These should probably be changed to just .siblingChanged(), seeing as
origEnd's new sibling wasn't just created.)
Fix another edge case where ghost may not be at end

As you can see in the test case, the edge case is if you have:

    ([1+2]+{3+4})+5

where the open-bracket and close-brace are ghosts, and you delete the
outer open-paren, so it becomes:

    (1+2]+{3+4}+5

Before, the close-brace would remain a ghost, just hanging out, not at
the end of its block. Now, we call .siblingCreated() on the brace to
solidify it.

Note that there's again no need for a symmetric call to origEnd's new
sibling because it gets .siblingDeleted() called on it by
Controller::deleteDir (in keystrokes.js).

(Bracket::unwrap() should probably be making .siblingChanged() calls on
both sides of the unwrapped paren? But whatever; Cursor::unwrapGramp()
fails to call .siblingChanged() on the contents of the unwrapped command
too, so like, if you type `1/2+3)` (which gets you
`\frac{1}{\left(2+3\right)}`, with the open-paren a ghost), then delete
forward (which unwraps the fraction), you get `1(2+3)` with the
open-paren still a ghost, but really, whatever. That'll be fixed when
.siblingChanged() is eventually done properly.)
Solidify ghost after being selected and replaced

e.g. by LiveFraction, as in test case
Merge branch 'feature.auto-expanding-parens' into myfork.gh-pages