Refactor Templates to expose platformExpander

This is needed to support the Windows build.
Clean up Utils.shakeToCabalVerbosity

Rather than use magic numbers which are needed when
issuing an external command to the cabal executable,
we can actually use Cabal's API value for verbosity,
then use fromEnum to convert back to an integer.
This change makes this function useable for mapping
Shake's verbosity to the Cabal API's verbosity.

hptool/src/Target.hs is modified to track this change.
Factor out localCommand into new file

The functions localCommand and localCommand'
(also helper function addPath') are moved from GhcDist
to a new file, hptool/src/LocalCommand.hs.  This
change allows these functions to now be used by the
OS-specific files, by preventing an import cycle.  The
other files included in this commit simply have their
imports modified (and note that most modules which
were importing GhcDist were doing so only for
localCommand.

* hptool/src/GhcDist.hs
* hptool/src/HaddockMaster.hs
* hptool/src/LocalCommand.hs
* hptool/src/Package.hs
* hptool/src/SourceTarballs.hs
* hptool/src/Target.hs
Correct spelling of "package.conf.d"

* hptool/src/Paths.hs
* hptool/src/Target.hs
Add LocalCommand to hptool.cabal

Forgotten file from "Factor out localCommand into new file"
missing return value in cabal.wrap
update to use GHC 7.8.3 - and bumped HP name to 2014.2.0.0
Merge pull request #123 from randen/windows-1

Remove brokenness from hptool.cabal file
Merge pull request #124 from randen/windows-1

Remove Windows-specific Data-files section
version bumps as per mailing list
Adding historical release information
Merge remote-tracking branch 'upstream/new-build' into new-build

Conflicts:
	hptool/src/Releases2014.hs
Minor cleanup in haddockMasterAction

* Open up OS record in haddockMasterAction
* Fix misspelling for haddockMasterAction
Swap (most of) OS.hs and OS/Internal.hs

The module OS.hs contained a function which selected the
appropriate OS-specific version of the OS record, based on
values from the BuildConfit record.  This is an important
function, used in half a dozen places.  A down-side of other
modules accessing this function through import of OS, is that
each module is also importing all of the OS-specific modules
which OS.hs imports. This leads to easily stumbling into
module import cycles, as bit of the functionaity get split
into, and taken into, the OS-specific modules, since numerous
modules import OS.

Note that OS re-exports OS/Internal.hs, since that is the
module with the actual definition of the OS record.  Ideally,
the higher-level modules would not need to know about/import
(indirectly) the OS-specific instances of the OS record; such
modules only need the definition of the OS record.  They
really only want to import OS.Internal, but they also have a
need for the osFromConfig function that OS.hs provides.

Moving the OS record from Internal.hs to OS.hs, and moving
the function osFromConfig from OS.hs to Internal.hs allows
all the higher-level modules to only depend upon and import
OS.hs, which is a types-only module after the swap.  No more
easily getting cyclical module dependencies.  To get access
to the osFromConfig function, it is not serializable, so it
is not suitable for Shake's Oracle mechanism of passing
"global" state around to Actions.  Since there were only a
few places that actually need the osFromConfig function, and
they are all driven from Main.hs when it is initializing all
the Rules, simply having Main.hs be the only module that
knows of OS.Internal and allow it to be the only place to
select the appropriate OS record instance, and then pass that
along to any Rules which need it, was very straight-foward.
Naming the argument the same as the function means even less
code changes.

An attempt was made to have as minimal changes as possible,
while also making sure all function arguments were still
needed (e.g., given an argument of type BuildConfig which was
only used within a function for a call to osFromConfig, the
BuildConfig was replaced by an OS record).

Modified:

* hptool/src/GhcDist.hs
  * Add osFromConfig function to ghcDistRules arguments
* hptool/src/HaddockMaster.hs
  * Change haddockDocDir function to use OS instead of
    BuildConfig
  * Add osFromConfig function to haddockMasterRules arguments
  * Add OS to haddockMasterAction
* hptool/src/Main.hs
  * import OS.Internal
  * add the osFromConfig argument where needed
* hptool/src/OS.hs
  * move osFromConfig to OS/Internal.hs
  * add the OS record definition, from OS/Internal.hs
  * fix up imports to be the minimal needed
* hptool/src/OS/Internal.hs
  * add osFromConfig from OS.hs
  * move the OS record definition to OS.hs
  * fix up imports to be the minimal needed
* hptool/src/OS/Mac.hs
  * import OS now, not OS.Internal
* hptool/src/OS/Win.hs
  * import OS now, not OS.Internal
* hptool/src/OS/Win/WinRules.hs
  * import OS now, not OS.Internal
* hptool/src/Target.hs
  * Add osFromConfig function to targetRules, buildRules
    arguments
  * Track related changes (e.g., haddockDocDir)
  * Use OS rather than BuildConfig for buildAction and
    for installRules
Fix html doc links between packages (Windows-only)

These changes may or may not make it easier for other
platforms to get the cross-package html urls to work
properly, as well as getting the master index urls set
properly.

* hptool/src/HaddockMaster.hs
  * Refactor haddockMasterAction so we can re-use the logic
    for getting the html interface info for the GHC and HP
    packages.
  * Add and export haddockGhcInterfaces and
    haddockHpInterfaces to expose the refactored parts of
    haddockMasterAction
  * Move the selection code for coreLibs and platformLibs to
    PlatformDB, which is more appropriate for where these
    should be, especially if exposing to other modules beyond
    HaddockMaster
  * Make use of two new OS-hooks to (optionally) munge the
    html path which comes back from the package conf info
    (this code allows the master index to use the correct,
    relative url links for all packages)
  * Make use of a new OS-hook, osGhcPkgHtmlFieldExtras, to
    optionally add switches to the ghc-pkg invocation when
    querying the haddock-html field
* hptool/src/OS.hs
  * Add a record, PkgInstallDirs, to capture all the
    directory paths needed for the invocation of "cabal
    configure"
  * Add two OS-hooks to optionally munge the html
    path which comes back from the package conf info
  * Add an OS-hook, osGhcPkgHtmlFieldExtras, to
    optionally add switches to the ghc-pkg invocation when
    querying the haddock-html field
  * Add an OS-hook, osCabalHaddockArgs, to optionally add
    switches to the invocation of "cabal haddock" when
    generating the package-specific html docs
  * Remove the osToCabalPrefix hook, as this is subsumed by
    osCabalHaddockArgs
* hptool/src/OS/Internal.hs
  * Track the OS changes, providing values for the new OS
    hooks so that the previous behavior is retained
* hptool/src/OS/Mac.hs
  * Track the OS changes, providing values for the new OS
    hooks so that the previous behavior is retained
* hptool/src/OS/Win.hs
  * From the OS.hs <-> Internal.hs "swap", the steps to move
    the doc and bin files for each package are no longer
    needed
  * Supply osGhcPkgHtmlFieldExtras to request ghc-pkg to not
    expand the pkgroot; this module will do that with a
    relative, rather than absolute, path
  * Implement the path munging functions which appropriately
    substitute the $topdir and ${pkgroot}
  * Provide osCabalHaddockArgs which is very similar to parts
    of HaddockMaster (thus the need for its refactoring) so
    that we can provide --read-interface= parameters for all
    packages when the "cabal haddock" task is run for
    generating the html docs for a particular package (this
    code is what allows the cross-package url links to be
    relative and relative to the correct location)
* hptool/src/OS/Win/WinRules.hs
  * Track OS changes
* hptool/src/OS/Win/WinUtils.hs
  * Move toCabalPrefix from Win.hs to here
* hptool/src/PlatformDB.hs
  * Move the coreLib and platformLib functions from
    HaddockMaster to here (with a bit of renaming to not
    conflict anywhere)
* hptool/src/Target.hs
  * Retain the lib dependencies (before adding alex or happy)
    in buildAction, for use with the cabal haddock changes
  * Use the new OS hook, osCabalHaddockArgs to provide
    additional (optional) command line args
  * Remove the --with-haddock part, as that, while a no-op
    for other platforms, seems only needed for Windows, so it
    is pushed into osCabalHaddockArgs
  * In the "cabal configure" step, use osPkgInstallDirs to
    set the various command-line args
Add check to install; warn user if other HPs found

The install will now check, as one of the very first
things, whether other Haskell Platforms are installed.
If any version (even the current version) is found,
a warning dialog is display, with a recommendation that
the user quit the current install, uninstall the others,
then restart the installer.