Dynamically create windows build job

This commit adds in the ability to create a dynamic jenkins job that
builds the windows MSI. It takes the git bundle used to build the linux
packages, and uses that version to build the msi.

We know to build the msi if :build_msi is set to true in
ext/build_defaults.yaml. If it is, then we're going to squeeze the msi
build job in after the packaging job, but before the repo job. If there
is a downstream job specified, that will be kicked off by the repo job
as always. If we are not building an msi, then the build pipeline
proceeds as normal (i.e. packaging => repo => downstream)

The main reasoning behind adding this work into the packaging repo is to
make it easier to build MSI's more frequently, and to have the versions
of all things in the msi in version control. Prior to this, the refs for
hiera/facter/puppet/etc. were tracked in the jenkins job itself. This
update allows us to maintain that information in ext/project_data.yaml.
Add template for msi jenkins job

This adds in the template for the msi job. If :build_msi => true, then
we use this template. The job is kicked off as a downstream to the
packaging job, and has the repo job as its downstream. Otherwise, we do
nothing with this template, and the repo job is downstream of packaging.
Shorten Jenkins job name

Since this dynamically created jenkins job has a longer name, it's
actually exceeding the maximum path length allowed on Windows (260
characters). This is causing the job to fail when it's cloning into
puppet-win32-ruby. In order to fix this, we're using the short sha
rather than the long sha to name the job. Reducing the path by about 20
characters seems to fix the problem. Don't worry, though. I'm sure this
will come back to bite us again soon.
(maint) use execution method

This updates some of our existing library methods to use the execution
method rather than %x{}. Moving to the future!!!