(#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.