CHEF-3012: Windows group provider is not idempotent for domain users

The root cause of this issue is that the underlying OS implementation of adding a domain member to a local group (failure case here) is different than the implementation of adding a local user or group to a local group. In the failure case, a different error status than expected is returned if the member already exists in the group.

The fix is to detect whether the members being added are already part of the group ahead of time, and only call the OS API for those members not in the group. The computation of this delta can be done by comparing each member with existing members in a canonical fashion. This is done by using a member's SID (security identifier, similar to uid in Unix), a unique ID in the domain's forest for domain members or on the local machine for local members. The Win32 method call LookupAccountName is used to get the sid for a member -- it correctly handles translating the name from domain\user format, and will handle cases where the same user name is used locally vs. in the domain.

One change from the original formulation @sersut -- there is code in the base class for the provider that checks to see if the membership has changed, and my changes caused that to alway say "yes" -- I added changes to allow derived classes to override part of that comparison (in this case, the Windows class uses the sid to compare membership so things work as expected).