Replace colorForSyntaxKind and ColorForRef with SourceWidgetTextPalette.

 * The new class consolidates syntax-coloring and ref-coloring into one
   place.

 * It allows use of any QColor, not just values in the Qt::GlobalColor
   enum.

 * There is a new SourceWidgetTextPalette::Color strong-enum that's only 8
   bits in size, which reduces the size of
   SourceWidgetView::m_syntaxColoring by a factor of four.

 * Each color in the palette has a preconstructed QPen, so
   SourceWidgetView::paintLine can now switch colors without creating
   a new QPen.  (Nor does this code have to call QColor::operator==.  It
   can instead compare SourceWidgetTextPalette::Color values, which is
   fast.)
Return an unrounded qreal value from the TextWidthCalculator.
In SourceWidgetView, track horizontal character positions using qreal.
SourceWidgetView: optimize the painting of consecutive ASCII characters.

 * The source widget draws one codepoint at a time.  This method does the
   wrong thing for bidirectional text and combining characters, and it
   doesn't join adjacent characters together (e.g. for Arabic text).
   However, this method allows for much faster painting, especially on
   very long lines, where only part of the line is visible at once.

 * Previously, the source widget called QPainter::drawText for each
   codepoint.  This is too slow on OS X.  The problem is:
    - QPainter::drawText is just slower on OS X, apparently.
    - OS X has smooth/inertial scrolling using a touchpad, so it's typical
      to want to scroll many times a second, either a few pixels at once
      or a whole page at once.
   Qt5's text rendering is apparently much faster than Qt4's on OS X, but
   on the other hand, Qt5 provides Lion-style, semi-transparent scrollbars
   that appear on top of the scrolled content.  Each time the source view
   is scrolled, the entire view must be redrawn.

 * This new code optimizes the common case of sequences of ASCII
   characters.  It optimizes further when those characters are displayed
   in a monospace font.

 * Specifically, the new LineTextPainter class maintains queues of colored
   ASCII characters to paint.  (Non-ASCII characters bypass the queue and
   are painted one-by-one as before.)  Within each queue, the
   LineTextPainter class groups characters into strings to reduce the
   number of QPainter::drawText calls.

   When a line alternates between colors, the LineTextPainter tries to
   insert space characters into the queue strings.  For example, the line
   "0+0+0" generally results in a queue of "0 0 0" of the numeric color and
   a "+ +" queue of the operator color.  When the two lines are painted,
   they overlap.

   Whether it's necessary or not, the code also tries to ensure that, for
   every adjacent pair of painted characters, the two are painted in the
   same order regardless of the invalidation region.  Namely:
    - Non-ASCII character are always drawn first, one-by-one, in
      left-to-right order.
    - Otherwise, characters are drawn in ascending order by color number.
      Characters are drawn left-to-right, and they are drawn in the same
      QPainter::drawText call if and only if their trailing and leading
      edges meet exactly.

   My thinking is that two adjacent characters may slightly overlap in some
   situations, and if they do, we want to ensure that they're drawn
   consistently to avoid flicker.

   Two plausible optimizations would break the above property:
    - Using something other than a std::map for m_coloredLines, unless the
      container was sorted before painting.
    - Replacing the ColoredLine::parts vector with a ColoredPart singleton.
      Conceivably, we don't really need to keep around previous parts -- we
      could flush one part as soon as another part was added.  Doing so
      breaks the ordering guarantee, though.

   The source widget (via LineLayout) assumes that each codepoint is
   positioned just to the right of the previous codepoint.  I trust that
   QPainter::drawText will lay out a string of ASCII characters like this,
   but I don't trust it with a string of arbitrary Unicode codepoints.  It
   is likely that a combining character, for example, would be painted on
   top of the previous character rather than after it.  Therefore, only
   sequences of ASCII character are optimized.
Fix an out-of-bounds memory access bug in the LineLayout class.

 * The first calls to hasMoreChars and advanceChar called nextCharIndex
   with m_charIndex equal to -1, which read the byte prior to the start of
   the line.

 * Fix the bug by adding an m_charNextIndex field, which is initialized to
   0 at the start of the line and updated for each character processed.
   This also reduces the per-character calls to utf8CharLen from 2 to 1.
Fix a display glitch with text rendering in the source widget.

 * When drawing a character, some of the drawn pixels may be to the left or
   the right of the bounding box defined by the character's "left" and
   "width" properties, and therefore, a character that needs to be drawn
   won't be drawn because SourceWidgetView::paintLine thinks it is outside
   of the invalidated region.

 * Fix this by expanding the character bounding box by a "horizontal bleed"
   value on the left and right.  I thought I could use the
   QFontMetricsF::min{Left,Right}Bearing methods, but using these methods
   does not work in all cases, so as a heuristic, expand the horizontal
   bleed value with the width of a space character, too.

   (Specifically, the methods do not work with the U+0651 codepoint on OS X
   with the Menlo 30pt font.  According to QFontMetricsF, the codepoint's
   width is 0, its left/right bearings are negative, but the font's minimum
   left/right bearings are 0.  QFontMetricsF::boundingRect seems more
   accurate, but I am concerned that it will be very slow, and I don't need
   much accuracy when computing a conservative bounding box.)