(#18268) Remove unnecessary startup mode components

This removes a property and a default value that are unnecessary to the startup
mode. This also removes three custom actions that could potentially cause
issues if they are not called in all scenarios (i.e. repair mode).
Merge pull request #60 from ferventcoder/ticket/master/18268-specify_service_start_mode

(#18268) Remove unnecessary startup mode components
(#22906) remember properties during upgrade

In previous versions of puppet, we did not overwrite existing settings. Now
that we are with the work done in #20281, we have found that the way we are
doing the remember me property doesn't work with the way we were doing
default values. This change fixes the default values to move them to a
customaction that happens just after the commandline / registry search to set
the value. If there is still no value, then the value is set to a default.
This happens prior to the GUI so a value from the registry or supplied on the
command line will show up as the value in the UI boxes.
(#21243) Allow windows service to run as different users

Previously, the puppet windows service always ran as the LocalSystem account,
which is fairly standard for agents that need to install arbitrary packages,
modify file permissions, etc.

However, the LocalSystem account does not have any credentials with which to
access network resources, e.g. SMB network shares. As a result, the standard
way of handling this is to run the service under a domain service account, and
add the service to the local administrators group on the computer.

This commit allows the service domain, account and password to be specified.
The account must already exist. The installer will grant the logon as a service
right to the account, and will add the account to the local Administrators
group.

If the account does not exist, the install will fail. If you've enabled
logging, e.g. /l*v install.log, you should see:

    Error 0x80070534: Failed to get SID for user: .\albert

If the password is wrong, the install will fail with:

    Error 1920. Service 'Puppet Agent' (puppet) failed to start.
    Verify that you have sufficient privileges to start system services.

If the service is currently running as something other than LocalSystem, then
you must re-specify the credentials when installing a new version. Otherwise,
the service will revert back to the default LocalSystem account.

To specify a local account, then specify the domain as the following:

    PUPPET_AGENT_ACCOUNT_DOMAIN=%COMPUTERNAME%
(#21243) Don't modify expiration policy for existing users

Previously, if an alternate service account was specified, the installer
would change the account to never expire, which is not something we want
to do.

This commit no longer modifies the account. This means if puppet is
configured to run as a domain or local account, and the account expires,
then puppet will not start.
(#21243) Use computer name as the domain if none specified

Previously, in order to execute the service under a local account, you had
to specify the local computer name for the domain:

    PUPPET_AGENT_ACCOUNT_DOMAIN=%COMPUTERNAME%

and specifying a domain of `.` is not technically valid, though it's what
most users would try to do.

This commit changes the installer so that if the DOMAIN property is not
specified or is specified as '.' on the command line, then the DOMAIN
property will be set to the local computer name.
(#21243) Domain must be NT AUTHORITY for some service accounts

Previously, trying to install the service to run as LocalService or
NetworkService would fail, because those accounts must have a domain
component of NT AUTHORITY. This is unlike the LocalSystem or local users
accounts which are of the form <computername>\LocalSystem.

This commit always sets the PUPPET_AGENT_ACCOUNT_DOMAIN to NT AUTHORITY if
PUPPET_AGENT_ACCOUNT_USER is specified as either LocalService or
NetworkService.

Ideally, I would have liked to create two SetProperty elements to set the
DOMAIN property based on different conditions. But this results in two
custom actions with the same name. The `Action` attribute allows the
custom action name to be specified uniquely, but it is only available in
WiX 3.6, and we're on 3.5. So instead, I create two custom actions, and
invoke them from both install sequences.
Merge branch 'ticket/master/22906-ensure_remembered_properties' of git://github.com/ferventcoder/puppet_for_the_win

* 'ticket/master/22906-ensure_remembered_properties' of git://github.com/ferventcoder/puppet_for_the_win:
  (#22906) remember properties during upgrade
(maint) test-installer.ps1 PowerShell msi tester

 - simply run test-installer.ps1 to have 14 different installer
   command line parameter variations executed / tested including:
   - no parameters
   - accounts using . as a domain
   - accounts using the local hostname as domain
   - LocalService
   - NetworkService
   - variations of installer startup type
Merge pull request #62 from Iristyle/maint/master/test-installer

Simple test script for built MSI