Fixes Qt5 plugin loading for all environments
While this is a relatively small commit, a great deal of testing, logging, and trial & error went into this to make sure it worked in all scenarios.  These scenarios include (for both Windows & OSX) running the apps (from the build directory, the _CPack_Packages directory, and the install directory), loading the OpenStudio plug-in within SketchUp (from the build directory, the _CPack_Packages directory, and the install directory), loading the ruby bindings on the command line (from the build directory, the _CPack_Packages directory, and the install directory), and loading the apps with a prior, incompatible version of Qt installed.

The goal was to make the change entirely in code and avoid changing environment variables, modifying the SketchUp directory, or anything else less than ideal.  In short, the solution is to call the static QCoreApplication::addLibraryPath function with the correct plugin path immediately before creating the QApplication object.

Now, some details about the Qt5 plugin system, what works and what doesn't, and order of operations.
- Plugins are loaded according to QCoreApplication::libraryPaths(), starting with the first entry in the list.  This list will only ever contain directories that exist, it doesn't contain duplicates, and by default it contains only the Qt directory.  Once the QApplication object has been created, it also contains the applications run path as the secondary location.  So for Windows, running an app from the build directory would look like this by default:
    C:/Qt/5.3/msvc2013_opengl/plugins
    C:/OpenStudio.1.5.0/build_release/OpenStudioCore-prefix/src/OpenStudioCore-build/Products/Release
The application run path that is added at the end of the list is not useful, as it can be an OpenStudio, SketchUp, ruby, or other directory that has invoked OpenStudio to create a QApplication.
The problem is that the qpa (Qt platform abstraction) plugin (e.g. qwindows.dll) is loaded as soon as the QApplication is instantiated, so the correct location to find that plugin needs to be at the top of the list prior to creating the QApplication.  For SketchUp and the ruby bindings, the first path needs to be the location of the ruby libraries.
- Calling addLibraryPath gives that particular path the highest priority.  Prior calls to addLibraryPath path will immediately follow the most recent one in the list.  Next is the Qt path, if it exists, followed by the path from the QT_PLUGIN_PATH environment variable.  qt.conf files also play some role in determining plugin locations, but that part is not as clear and completely useless for SketchUp and ruby, so I didn't pursue that route.  The qputenv function can be successfully used to set QT_PLUGIN_PATH before creating the QApplication, but since the result of this variable is at the end of the library paths, it's not useful.  Calling addLibraryPath with a path that already exists in the list will move it to the top.
- Previously on Windows, we were setting the QT_PLUGIN_PATH environment variable at the system level to help SketchUp and ruby locate the plugins (it can contain multiple paths).  In addition to being less than ideal by modifying the environment, the Qt directory used to build OpenStudio was still the top library path, so if it was installed on a system with Qt 5.3.x, it would load the plugins from the wrong location.  This caused a problem when OpenStudio was built with Qt 5.3.2 and it found 5.3.0 installed on a different computer, since they use the same install directory.  It crashed silently because the qsqlite plugin versions where incompatible.

- Loading the apps directly from a build directory will search for plugins first in the run path (not found) and then look for them in the Qt location (found).  Loading the apps directly from a non-build directory will find the plugins in the run path.  Loading the ruby bindings from a build directory will search for plugins first in the run path's ruby build directory (not found) and then look for them in the QT location (found).  Loading the ruby bindings from a non-build directory will find the plugins in the ruby directory.  Note that the run path for the ruby bindings on mac from a build directory is the OpenStudio.app bundle, not the ruby build directory.

- The qpa plugin is the first one loaded (when the QApplication is instantiated).  Next, plugins are loaded as needed (sqlite, printsupport), but it's worth mentioning that some plugins that we don't package or request can be found and loaded automatically from supplementary library paths.  This typically happens with the image format plugins.  If this ever becomes an issue (with incompatible versions, perhaps), we can make the loading paths stricter (explicitly remove the Qt path) or we can package these plugins ourselves for good measure.

- Trying to use the QPluginLoader class to preload the necessary platform plugin before creating the QApplication object successfully loads the plugin, but does not actually work when QtCore tries to find it.

FYI, @macumber @lefticus @kbenne since you guys have all had to deal with plugins at one time or another