Initial commit at cleaning up generated enums
Swap out more OPENSTUDIO_ENUM with generated code
Add missing WriteEnums.hpp file
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
Updating templates
Adding 1.5.0 release notes
Fixing bug found by Matt Brown today, I'm not sure why some reporting measures have the measure script mapped to two required files (user_script.rb and measure.rb) and others only have it mapped to one (user_script.rb).

[#79629750]
Merge pull request #1218 from NREL/79629750_ReportRequestCalibration

Fixing bug found by Matt Brown today, I'm not sure why some reporting me...
Fix PCH for Release builds
Finish cleaning up of faster compiling enums
Add EnumBase.hpp
Fix PCH on MSVC
Fixes #1221
Merge remote-tracking branch 'origin/develop' into CleanerEnums
Merge pull request #1222 from NREL/UniqueSizingParameters

Fixes #1221
Fixing clang warnings
Fixing cyclic CMake dependency
Work around crash on exit of Sketchup

 - Seems with  the new sketchup, doing almost anything with the
   sketchup API causes a crash or hang, as the system is in a
   shutting down state
 - Also seems that during shutdown, we don't need to do the
   full model detaching process, as most of it is UI cleanuis,
   which have implicitly already completed at this point
 - Also, because the UI has already asked if a save should occur
   nothing that is done will be saved
 - This leaves only the cleaning up of the OSM temp dir that needs
   to occur. This is now done in the "shutdown*" methods added
   with this commit.

@macumber @axelstudios please review
Fixes #1206
Merge branch 'FixWarnings' into develop