Add typing.test.js tests for LiveFraction #test

Also EditableField::typedText() now accepts a string rather than only
single characters, and simulates typing the string of text one character
at a time.
Add optional direction to Fragment() constructor

a la Cursor::withDirInsertAt, but as a last and optional argument
(defaults to L, which is equivalent to the original behavior).
Merge branch 'fix.focus-ring' into feature.auto-expanding-parens
First pass horizontal panning  #cherrypick

Since a wrapping behavior for math is ill-specified, mathquill fields
now pan like <input/>'s.

So for dumb reasons, CSS2.1 specifies that the baseline of an
inline-block that is overflow:hidden is its bottom margin edge [1]
(not for no reason, I admit [2]). For now just set vertical-align:middle
to look reasonable for the common case, eventually I'll adjust the
vertical-align numerically in JS (after all, I already have
Node::expectedCursorYInside).

[1]: http://lists.w3.org/Archives/Public/www-style/2013Jul/0188.html
[2]: http://lists.w3.org/Archives/Public/www-style/2013Jul/0471.html

Note the comment above &:after[3].

[3]: https://bugs.webkit.org/show_bug.cgi?id=35443#c1

The margin-right was switched to margin-left in order to fix a 1px shift
when the cursor is at right edge in Firefox.  The cursor had a negative
`margin-right` so when it's at the right edge, it overflows which
increases the `scrollWidth1 and since `.scrollHoriz()` is pushing to
scroll as far right as possible, the entire editable scrolls to the
right by 1px.

Shrink textarea to smallest nonzero width and height so it won't affect
the minimum scroll{Width,Height} of the container. This took quite a
while to track down the other day, the only symptom was that the
scrollWidth was a weirdly big number, there's not a lot of people
talking about what affects scrollWidth. (Must be nonzero so that
textarea is visible and hence focusable.)

The basic idea behind `_.scrollHoriz` is to scroll by a minimal amount
while maximizing the amount of the selection shown, and while keeping
the cursor within inner bounds of the textbox (i.e. 20px from the
edges).
Deduplicate asserts in typing.test.js #cleanup
EditableField::keystroke() now takes list of keys

Obsoletes the move() helper fn in updown.test.js
Parens now have a ghost that auto-expands to end #big

When brackets are now typed, they come with a matching "ghost" bracket
at the far end of the current block. This is done by auto-expanding to
contain the rest of current block and being set to a "one-sided" state.

Then, typing a matching bracket facing the opposite way in a one-sided
bracket "closes" the matching bracket pair around anything between them.
This is done by moving everything up til the ghost outside the bracket
pair and "solidifying" the ghost.

Also, having to add {Node,Fragment}::withDirAdopt() was annoying.
Not sure what could be done about that; it's non-trivial to
directionalize Fragment::adopt, its implementation relies on the
order that .each() iterates through the nodes.
Parens/brackets/braces now deleted one at a time

You can now delete one of a pair of matching brackets, which turns into
a ghost and auto-expands to the far end of the current block, making the
pair one-sided again. Deleting the non-ghost side of a one-sided bracket
deletes it completely.

The .delete{Towards,OutOf}() architecture is so great! But not the
having to monkey-patch methods on the sole MathBlock in finalizeTree,
that sucks.
Fix parens from LaTeX or wrapping seln being one-sided

Had to move HTML template out of constructor, so that .side can be set
later based on whether .replaces() was called or whether the paren was
created by the parser.
Allow mis-matched parens/brackets like [a, b)

Store on each Bracket the characters and control sequences of each side,
and swap them out when closing a one-sided bracket by typing a bracket
facing the opposite way. Also, when deleting one of a mis-matched pair
of brackets, the ghost is always a matching opposite of the remaining
side of the bracket.

Parser now calls Bracket constructor with arguments based on the
characters immediately after each of \left and \right, like it should,
rather than always a matched pair based on the character immediately
after \left.

All the tests that try deleting the parens from various permutations of
an expression with a paren pair in it, change to deleting a mis-matched
bracket pair. It's more general, I'm not really worried about something
working for a mis-matched pair but not a matching one, whereas I am
about the reverse.

Resolves mathquill/mathquill#150.
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