(#20768) Don't confuse WMI and IADsUser automation objects

To enumerate local users (and groups), we execute a WMI query. The query
returns an array of generic WIN32OLE objects, each of which wraps an OLE
automation object. The WIN32OLE object uses method_missing to dispatch
method calls to the underlying automation object.

In the case of a WMI query for users, the underlying automation object
provides the methods and properties defined by the Win32_UserAccount
class[1], e.g.  AccountType, Caption, etc.

Previously, we were creating instances of Puppet::Util::ADSI::User and
passing in a WIN32OLE object wrapping the WMI automation object, when it
expects a WIN32OLE object wrapping an IADsUser[2] object.

This never caused a problem, because the windows ADSI user provider's
instances method only enumerates the user names on the systems and
creates new Puppet::Util::ADSI::User objects from them.

However, if you had ever called Puppet::Util::ADSI::User.each
programmatically, and then called a method that used the WIN32OLE
object, e.g. native_user.Get('HomeDirectory'), it would fail since the
WMI based automation object doesn't implement the 'Get' method.

This commit changes the 'User.each' method to not pass in a native_user
object. Instead, we create the correct native_user object lazily.

The same issue existed for 'Puppet::Util::ADSI::Group.each' as well.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa394507(v=vs.85).aspx
[2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa746340(v=vs.85).aspx
(#20768) Only query on the name field

Previously, we loaded entire WMI objects from the query, assuming they
were needed by the ADSI objects. But this was incorrect and never
worked.

Since we only need the User and Group names, we can select only those
fields.
(#20768) Use the correct Win32API method signatures

In ruby 1.8, we could call CloseHandle passing it the handle (an opaque
unsigned integer value), and due to the 'P' in the method signature,
automatically arrayify and pack the handle. This wasn't done intentionally,
it just happened to work.

But ruby 1.9 no longer automatically coerces the parameter, instead
the CloseHandle method (implemented by the windows-pr gem) tries to pack
the handle, generating an error `can't convert Fixnum into String`. This
prevents puppet from managing a user's password and home directory.

The proper fix is to define the CloseHandle method signature correctly, so
that the windows-pr layer doesn't attempt to coerce the handle value.

The UnloadUserProfile API had a similar problem, it takes the handle as an
'L' input paramter (instead of a pointer).
(#20768) Enable managehome acceptance test on Windows

This commit enables the acceptance test on windows. On 2003, the default
home directory is C:\Documents and Settings\username. On Vista and
later, it is C:\Users\username. In the 2003 case, the home directory
needs to be quoted, e.g. when passed on the command line.
(#20768) Refactor base profile logic

This commit refactors the logic for figuring out the base profile
directory, e.g. C:\Users or C:\Documents and Settings, and updates the
acceptance test to use it. The `--helper` option must be used in the
systest harness so that the LOAD_PATH is setup correctly to find the
windows_util.rb helper, but this should already be the case for
temp_file_utils.rb, etc.
(#20768) Windows can now create the home directory (again)

The previously pending_test method was used, because puppet couldn't
create the home directory when creating the user in ruby 1.9 on windows.
Now that that is resolved, we can remove the windows-specific
pending_test. Note, that the test will still be pending later, since
neither the windows nor useradd providers correctly move the user's home
directory.