Feature: 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][2], I admit). 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).