Fix vertical alignment of binomial's parens

They're vertical-align:bottom, so need an inline-block container or else
they'll be aligned with the bottom of the containing block, as in the
test case.

Recommend -w to view diff.
Factor out DelimsMixin from Bracket, Binom

Name based on TeX primitives like \overwithdelims
Fix auto-expanded paren block nonempty but gray

Specifically, if you have `()+stuff` (where there should be a gray box
in the empty paren block) and backspace the close-paren, the paren
auto-expands to the right end of the block but the paren block (now
containing `+stuff`) remains gray.

An alternative fix for this is for Cursor::insDirOf (which is called the
line after the next after the one-liner fix) to call this.parent.focus()
instead of directly doing `this.parent.jQ.addClass('hasCursor')`. The
reason it doesn't already is that `.jQ.removeClass('empty')` is normally
unnecessary when inserting the cursor next to something, because if
there's something to insert the cursor next to, the parent must not be
empty. This is the first case ever that might possibly be an exception,
and if we've been micro-optimizing, why stop now? Bad habits die hard.
Say "close-paren" not "close paren" in test names #test #cosmetic
Say "paren group" not "bracket pair" in test names #test #cosmetic

Even though "bracket" is more general, paren is more what comes to mind,
and want consistency with, for example, the name of the section,
"auto-expanding parens".
More specific paren group backspacing test names #test #cosmetic
Move a paren test to more appropriate section #test #cosmetic

It's a test not about backspacing, but about solidifying ghosts, which
has it's own section.
Pipes now have a ghost that auto-expands to the end #hard

feature.auto-expanding-parens #262 removed '|' from CharCmds and never
added anything back, so pipes were just VanillaSymbol's.

Note that transient ghosts pretty much resolves #81: typing nested
absolute values is still more annoying than typing nested parens,
because inside the one-sided absolute value, typing the first pipe still
closes the absolute value, but now that the ghost has been solidified
you can go Left and just type the inner absolute value; whereas
originally, there was no one-sided/ghost state, you just couldn't type
an inner absolute value at the end.

This commit makes the new auto-expanding and deleted-one-side-at-a-time
Bracket well-behaved for pipes, mainly by changing Bracket::oppBrack.
A pipe may close a one-sided bracket facing either way (unlike a bracket
which may only close a one-sided bracket facing the opposite way), and
which way a one-sided pipe has to be facing to be be closed by the pipe
currently being typed or deleted is only known by the caller of
Bracket::oppBrack and so is now a parameter (optional in one case).

This was hard to implement at all, doubly so to make it understandable.
I started off with no idea what needed to be changed in Bracket
(something about Bracket::oppBrack obviously, but what and what else?)
and copy-pasted the entirety of Bracket as a separate Pipe class (hence
factoring out the DelimsMixin) and modified it so that just typing and
deleting pipes worked (no mis-matched pipe/paren groups, of course),
saw that they were still largely duplicated and also realized that LaTeX
rendering was a complication (a mis-matched pipe/paren group would be
rendered as a Bracket, of course, but what happens when you delete the
paren? I can't just switch classes), painstakingly refactored Bracket to
incorporate the changes in a minimal way while keeping preventing
mis-matched pipe/paren groups, until finally realizing it can be simpler
both to implement and to explain allowing them.

For posterity, replacing Bracket::oppBrack with the following will
prevent typing mis-matched pipe/paren groups while keeping everything
else working:

  _.oppBrack = function(node, expectedNodeSide) {
    return node instanceof Bracket && node.side // node must be 1-sided bracket
      && node.side !== -expectedNodeSide // of expected side (if specified);
      && (node.sides[node.side].ch === '|' // is match if both are pipes, or
          ? this.sides[this.side].ch === '|' // neither and opposite sides
          : (this.sides[this.side].ch !== '|' && node.side === -this.side))
      && node;
  };

But if you're gonna restrict mis-matched bracket groups, there's no
reason to allow mis-matched curly brace groups, really the only common
ones are half-open half-closed intervals, (a,b] and [a,b). For now, err
on the side of expressiveness, it's only even possibly a usability issue
in the presence of ghosts, which are deliberately very transient.
Brackets and pipes get bigger nesting level #visual #usability

In |a + |b||, the outer pipes should be bigger to visually distinguish
the delimiters for the outer absolute value from the inner absolute
value. While less important, this also makes nested parenthesis look
more right.
Merge branch 'feature.pipes' into dev