Centralize font configuration in a new Nav::Application class.

 * Use QSettings to read font settings, which will let the user override
   them.

 * Pick reasonable defaults for Linux and for OS X.
Provide fall-back prev/next/close icons for the toolbar and FindBar.

 * This is needed on OS X and Windows, where Qt does not have themed icons.

 * These icons come from the famfamfam Silk 1.3 set and are available
   under the Creative Commons Attribution 2.5 License.
OS X: Use a more appropriate Back/Forward keyboard shortcuts.

 * Show the keyboard shortcut in the tooltip for the Back/Forward toolbar
   buttons.
Stop using the widget-in-a-viewport technique in the SourceWidget.

 * Previously, the SourceWidget was derived from QScrollArea, and its
   viewport contained a SourceWidgetView widget, which was at least big
   enough to show the entire content of the file.  Scrolling was
   implemented by moving the view widget, and as parts of the view widget
   were uncovered, those parts (and only those parts) were painted.

 * There are two problems with this approach.
    - It turns out that Qt can only really handle widgets up to 2**24
      pixels in size.  At 18 pixels per line, this limits the SourceWidget
      to files with 932067 lines.  So far, this hasn't been a serious
      restriction, but I hadn't anticipated it.  This was a problem with
      an earlier version of the GotoWindow/TableReportView.
    - On OS X, each time the view widget moves, the entire visible region
      is marked dirty and repainted.  This makes scrolling unusably slow.
      (Bear in mind that OS X has very smooth scrolling with a touchpad.)

 * The new approach keeps the SourceWidget/SourceWidgetView separation,
   but the SourceWidgetView widget is exactly the same size as the
   viewport.  The SourceWidgetLineArea widget is exactly the same size as
   the strip along the left side as the viewport.  Both widgets have a
   setViewportOrigin method, and they convert between real and virtual
   coordinates for painting and handling mouse events.

 * With this change, the SourceWidget is still sluggish, but it's much
   better than it was, at least when scrolling.

 * Note that with the touchpad, it's very easy to scroll both horizontally
   and vertically at the same time.  In this case, the update rectangle
   covers the entire SourceWidget.
Clean up includes in the navigator.

 * Include the Qt header for every type used in the file.  A lot of these
   includes are unnecessary (e.g. QObject, QString, QWidget, QColor), but
   I like having simpler rules for deciding which headers are included.

 * Remove some unnecessary includes.

 * Include <QApplication>, not <QtGui/QApplication>.  AFAIK, they both do
   the same thing, so this change is for consistency only.
Avoid use of stdint.h's limit macros, because they are non-portable.

 * There is a comment in the C99 standard saying that these limit macros
   should not be defined for C++ unless the __STDC_LIMIT_MACROS macro is
   defined.  (Bad idea)

 * The C++11 standard says that the cstdint header should ignore the
   __STDC_LIMIT_MACROS macro and define the limit macros unconditionally.
   (Good idea)

 * Clang's stdint.h appears to define the macros regardless of the
   __STDC_LIMIT_MACROS setting, except that it actually falls back on the
   host system's stdint.h.

 * glibc's stdint.h does not define the limit macros unless
   __STDC_LIMIT_MACROS is set, in conformance with C99.

 * To conform with C++11, libstdc++'s cstdint header temporarily guarantees
   that __STDC_LIMIT_MACROS is defined for the duration of its inclusion of
   stdint.h.

 * Once stdint.h is included somewhere, including it again (even indirectly
   via cstdint) has no effect.

 * Therefore, including cstdint does not guarantee that the limit macros
   will be defined.  (And, the current inclusion of stdint.h only appears
   to work because some other libstdc++ header is including cstdint first.)

 * Configuration macros (like __STDC_LIMIT_MACROS) are painful and best
   avoided.

 * Therefore, there's no easy/reliable way on Linux to use the limit
   macros from C++.  They aren't essential anyway, so replace them with a
   cast of -1.
Port the project to Qt5.

 * The code still works with Qt4.

 * With Qt5, the framework was modularized, and the widgets and
   QtConcurrent components are no longer available by default.  Add widgets
   and concurrent to the QT variable to get them back.

 * With Qt5, there is a CONFIG setting that enables C++11, so use that
   instead of specifying -std=c++11.  With Qt5 on OS X, setting
   QMAKE_MACOSX_DEPLOYMENT_TARGET no longer works, but there is a new
   mkspec file, macx-clang-libc++, that specifies both the deployment
   target and -stdlib=libc++.  This project requires use of that mkspec
   file for Qt5 on OS X.  (The configure script has not been updated yet
   for OS X, but it probably will be soon.)

 * Qt5 does not have a QTextCodec::setCodecForCStrings method anymore.
   In Qt4, this function controlled the codec used by the
   QString::fromAscii and QString::fromStdString methods.  In Qt5,
   QString::fromAscii is gone, and QString::fromStdString always uses the
   UTF-8 encoding.  Therefore, continue setting the default codec to UTF-8,
   but only for Qt4, and replace QString::fromAscii calls with
   QString::fromUtf8 calls.

 * Two QHeader methods were renamed, so call the new methods:
    - setClickable to setSectionsClickable
    - setResizeMode to setSectionResizeMode

 * Two of the calls to effectiveLineSpacing should have passed a
   QFontMetrics object, not a QFont object.  This mistake wasn't caught
   previously because Qt4 had an implicit QFontMetrics(QFont)
   constructor.  The constructor is explicit in Qt5.
Use the paint region, not just the bounding rect, to elide QPainter calls.

 * It is especially important to avoid unnecessary character drawing on
   OS X, where the user may pan the source view in both directions at
   once, or where the invalidated region may include both the auto-hide,
   semi-transparent scrollbar and also a small strip of the source view.

 * I'm unsure about the kLineBleedPx code.  My thought was that some glyphs
   from an adjacent line might sometimes extend vertically into a line,
   making it necessary to draw the adjacent lines.  The
   "lineHeight / 2 + 1" bleed amount is just a guess, though.