Add windows detect_installer capability

Initial implementation is basic and does not contain excellent error
checking, but for any distribution of Windows and any architecture the
installer will be the same, so not really a hugely complicated effort.
Add windows run_install capability

This required the modification of the archive object behavior to deal
with the Windows installer, which is an MSI file, not a tarball.
Isolate archive unpacking logic in PEBuild::Unpack

This makes archive that much cleaner, and clearly isolates the logic for
determining what action to take to correctly deploy a given kind of
installer archive.
Add Windows Server 2003 support

Windows Server 2003 support wasn't added as I didn't originally have a
test machine or a need. After comments in Github and a few more spare
minutes it seemed like an easy win, so here it THEORETICALLY is. This is
not yet tested on a Windows Server 2003 machine, but it IS tested on
Windows Server 2008 (works great) and SHOULD also work on Server 2003.
Remove redundant logic in windows detect_installer

The stubs will probably never be used due to possible future API
changes, so no point having them. If they're ACTUALLY needed later it's
easy enough to build them out again.
Merge pull request #33 from reidmv/windows-support

Windows support
Update CHANGELOG and version for 0.5.0
[unpack] Support simple .tar archives, extract .tar.gz

PE archives can be both simple tar archives as well as gzipped archives.
This commit extracts the pure tar archive handling into a standalone
class, and adds a tar.gz class for gzipped archives.
[archive] .tar and .tar.gz from installer_dir name

This isn't sustainable in a long term manner, but gets us to the next
release. I am ashamed.
Merge branch 'pure-tar-unpacker'
[release] Fall back to latest release on missing release

The current version of PE release lookup would silently return nothing
if a requested version of PE was not defined. This would cause calling
methods to fail horribly with a noisy stack trace.

This commit adds a warning when the requested version is missing and
falls back to the latest version, so at lease the end user has a rough
idea of what's going on.
[config] Change private validate functions to arity 2

Some configuration validation must be within the context of a validated
machine, but the individual validate methods did not have access to that
data. This commit makes all of the individual validate methods arity 2,
for the error array and the currently validating machine.
[config/global] Allow PE versions to include rc builds
[config/pe_bootstrap] Don't revalidate version

The parent method definition of Config::PEBootstrap#validate already
calls #validate_version, we shouldn't call it again in the child class.
[provisioner/pe_boostrap] Finalize global config first
Merge branch 'config-validate-arity'
[config] require config filename to be finalized

Earlier versions of pe_build did ad-hoc merging/finalizing of the
Config::Global and Config::PEBoostrap objects, which lead to a lot of
methods that behaved lazily. This made it very hard to reason about what
the filename actually was.

This commit requires that the configuration object be finalized before
accessing the filename, and adds sane handling for filename decection when
the filename is explicitly given.
Merge branch 'config-finalize-filename'
Update CHANGELOG and version for 0.6.0
(maint) reindent files to conform to arbitrary best practices.

protip: if you're using git blame and see this commit, use
`git blame -w` or :Gblame -w if you're using vim. Also, I'm sorry you're
using git blame and I regret any mistakes I may have made.

Ruby namespacing is entirely based on constants, which also define
module and class names so things get weird.

If you accidentally call `class Foo` in one place and `module Bar` in
another, your code will explode, so you don't necessarily want to
redeclare all your namespaces in each. Also, the level of indentation
that can arise from deep namespaces gets nuts, and if you don't indent
at each constant then that looks weird.

On the other hand, it's very easy to require files in the wrong order.
If you have files 'foo' and 'foo/bar' where 'foo' requires 'foo/bar' and
then defines `module Foo`, and 'foo/bar' defines `class Foo::Bar`, the
constant Foo won't be defined and your code will crashed.

Namespacing in Ruby sucks.

To solve this, this commit adds the following convention. Files that
implement a public interface should have all constants specified and
should require all files under that namespace, like so:

    module PEBuild
      module Unpack
        require 'pe_build/unpack/copy'
        require 'pe_build/unpack/tar'
        require 'pe_build/unpack/tar_gz'
      end
    end

Requires files should be formatted like so:

    require 'pe_build/unpack'

    class PEBuild::Unpack::TarGZ < PEBuild::Unpack
    end

All files being require should probably require their parent, but should
_not_ be directly required. Classes that depend on a sibling file should
rely on the parent to require it. This has the nice side effect of forcing
implementations to be astracted.