(#11870) Add registry module

Ruby includes a built-in set of modules and classes for interacting with
the registry, however, it is only present on Windows.  This makes it
difficult to write spec tests that can run on non-Windows platforms due to
the `Win32` namespace and related constants.

This commit adds a utility module to wrap the Windows specific code.  This
way if you write a module/class that uses the registry, you can just add
expects/stub expectations to the utility module or the class that
includes/extends it.
(#11870) Refactor windows-specific requires

Previously, we were explicitly requiring windows-specific code, which
made it hard to write spec tests that still run on non-Windows platforms.

This commit refactors the requires into the
`Puppet.features.microsoft_windows?` definition, so that if we are on
Windows all of our dependencies will be satisified, and if we're not on
Windows, we won't accidentally load code that doesn't apply.  Also,
re-ordered the dependencies based on where they come from, e.g. ruby vs
gem.
(#11870) Add package options parameter

This commit adds a new package options parameter type that accepts an
array of strings or hashes. For example,

    [ 'arg1', { 'key2' => 'val2', 'key2' => 'val3' }, 'arg4' ]

The parameter preserves the order of array elements, as it may be
significant for a provider, e.g. '--source', 'URL'. Order of hash
key-value pairs is based on the natural sort order of the keys. Any
argument containing spaces will automatically be quoted, so that you don't
have to check that in each manifest.

The package options parameter is not currently used, but will be in a
future commit to enable install and uninstall options to be passed to the
package provider.

Oddly, if any puppet parameter is specifed as an array with one element,
puppet's parser-based resource will automatically de-arrify it (see commit
46252b5b). As a result, if an array is a valid value, then the validate &
munge methods cannot reject an element that isn't an array.

Therefore, the package options munge method arrayifies values, which has
the side-efect that it will accept the 2.7.x style way of declaring
install_options for MSI packages. Moreso, it means that the old way cannot
be deprecated without changing core puppet behavior.
(#11870) Refactor the MSI provider to use package options

Previously, the MSI provider contained logic for accepting a hash of
`install_options`. The provider's install method flattened the hash pairs
as:

    "key1=value1 key2=value2"

and passed that to msiexec.exe. This worked fine for MSI public
properties, but does not account for passing single arguments.

This commit refactors the provider to use the more generic version of
`install_options`, which expects an array of values. For example, if a
manifest contains:

    [ '/S', { 'INSTALLDIR' => 'C:\Program Files' } ]

then msiexec will be invoked with:

    "/S INSTALLDIR=\"C:\\Program Files\""

The only change in behavior is that the MSI provider will now accept
single arguments and pass those onto msiexec.
(#11870) Add the ability to specify uninstall_options

Previously, the MSI provider was unable to specify uninstall_options.
This isn't typically an issue, since Windows stores the command and
arguments necessary to uninstall the package in the `UninstallString`
registry value associated with the package.

But there are some MSI packages that require this functionality, e.g. to
specify VMware Tools modules to uninstall:

   msiexec.exe /x <productcode> REMOVE=Sync,VSS,...

This commit adds an `uninstall_options` parameter to the package type and
updates the MSI provider to use it. It has the same format as
`install_options`.
(#11870) Deprecate the `:msi` provider

The `:msi` package provider is being deprecated and replaced with the
`:windows` provider. Attempting to install or uninstall a package using
the msi provider will cause puppet to issue a deprecation warning.

The windows provider is basically a copy of the MSI provider, though it
will be capable of managing executable packages in a future commit.
(#11870) Refactor package management logic for MSI

This commit moves the logic for querying, installing and uninstalling MSI
packages into a MsiPackage class separate from the main windows package
provider. This is being done in preparation for adding executable package
support (as some of the logic is very similar), such as querying the
registry for installed products. Additionally, executable and MSI
packages can be related, which makes partitioning the set of installed
packages into different MSI and executable providers not really feasible.
(#11870) Manage executable packages on Windows

Previously, puppet could only manage MSI packages on Windows. This commit
extends the `:windows` package provider so that it can query, install, and
uninstall executable packages. The logic for this is borrowed from[1].

Basically, puppet will only manage executable packages that have the
following attributes:

    Non-empty DisplayName
    Non-empty UninstallString
    Are not SystemComponents
    Are not WindowsInstaller
    Names don't start with KBXXXXXX
    Are not part of another product (ParentKeyName)
    Are not Security Update, Update Rollup or Hotfix

For example, to install Java silently:

    package { 'Java(TM) 7 Update 5':
      ensure          => installed,
      source          => '...\jre-7u5-windows-i586.exe',
      install_options => [
        '/s', '/v/qn" ADDLOCAL=jrecore REBOOT=Suppress JAVAUPDATE=0"'
      ]
    }

[1] http://community.spiceworks.com/how_to/show/2238