(#17031) Use SIDs to modify ADSI group membership

 - New #add_member_sid / #remove_member_sid methods do the heavy
   lifting inside of Puppet::Util::ADSI::User to add / remove group
   members instead of relying on string names
 - Expose a new Puppet::Util::ADSI::User#sid method that returns
   a Win32::Security::SID instance with account, domain, and raw SID
 - Puppet::Util::ADSI::User#uri method now uses the #sid account and
   domain to build a URI
 - Since #uri now relies on #sid, which converts the binary value from
   the #native_user.objectSID byte array, the @native_user is initially
   populated by generating a throwaway uri built by parsing @name.
   This prevents a circular reference.  This effectively means the
   original given @name is parsed and given to ADSI.connect, and on
   connect, the raw SID generates a SID object.  Alternatively, a SID
   could have been generated by Win32::Security::SID first, its domain
   and account values then used to retrieve @native_user.
   Original semantics around @native_user were kept intact to prevent
   breaking existing callers.  In practice, this should have no effect.
 - Due to dependence on Windows::Security, some tests are now run only
   on Windows.  This was a trade off where it would have been possible
   to add an initializer param for @sid to Puppet::Util::ADSI::User, but
   it seemed cleaner not to