(PUP-2660) user: set the user should-value when generating ssh_authorized_keys

When purging authorized SSH keys, the user type generates ssh_authorized_keys
resources using eval_generate. The ensure property receives a should value of
"absent" so the keys are removed. However, those resources are non-functional
because the user property lacks a should value. The resource fails during
Provider::Ssh_authorized_keys::Parsed#flush.

Fixed by setting the appropriate user value for each generated key.
(PUP-2657) FFI Puppet::Util::Windows::Error

 - Remove dependency on 'windows/error'
 - Expand FFI helper methods from MemoryPointer to Pointer as we need
   them to operate on a chunk of memory that will be LocalFree'd (i.e.
   MemoryPointer is set to own the memory and autorelease when done)
 - Unfortunately, attempts to use FFI to call GetLastError were futile.
   FFI.errno should automatically be capturing the GetLastError result
   of any call made through FFI, however this doesn't appear to be the
   case in practice.  Furthermore, attempting to define GetLastError as
   a function in FFI yields the same result.  A number of tests fail
   as the error code is being stomped / swallowed.  The solution is to
   use Win32API.new to define / use this single function.  Sigh.
Merge pull request #2695 from Iristyle/ticket/master/PUP-2657-FFI-Puppet-Util-Windows-Error

(PUP-2657) FFI Puppet::Util::Windows:Error
Merge remote-tracking branch 'ffrank/ticket/3.6.1/PUP-2660-keys-not-purged-missing-user' into stable

* ffrank/ticket/3.6.1/PUP-2660-keys-not-purged-missing-user:
  (PUP-2660) user: set the user should-value when generating ssh_authorized_keys
(PUP-2639) Change default timeout to 3 minutes

The 5 second timeout was selected assuming that the major use case would
be around a development workflow in which a user edits manifests on a
master and then immediately runs an agent to see the effect. It turns
out that this caused a lot of problems for a much more common and
impactful case of users updating to directory environments where they
ended up with excessive CPU usage. Nearly any value here is arbitrary
except 0 (purely development workflow) and unlimited (best choice for
production systems).

This makes the almost arbitrary decision that a 3 minute timeout will
create less confusion for upgrading users. It means that a development
workflow will require more restarts, however. :(
Merge pull request #2710 from zaphod42/feature/stable/pup-2639-increase-environment-timeout

(PUP-2639) Change default timeout to 3 minutes
Merge remote-tracking branch 'upstream/stable'

* upstream/stable:
  (PUP-2639) Change default timeout to 3 minutes
  (PUP-2660) user: set the user should-value when generating ssh_authorized_keys