GSSAPI plugin - support AD for local group name , and SIDs on Windows

The GSSAPI plugin only accepts user if username matches, which for some use might be too restrictive.
Here https://mariadb.com/kb/en/the-community-is-chaining-upns-via-authentication_options-when-using-the-gs/ a user struggles to move from MySQL Windows authentication (which is GSSAPI, under the hood, mostly), and what he actually needs is a plugin supporting Active Directory group membership. This is easily done since on the server side we will get a user's token, and group membership is easily derived from the token.

The proposed syntax

GROUP prefix

CREATE USER root IDENTIFIED VIA gssapi as 'GROUP:Administrators'

CREATE USER root IDENTIFIED VIA gssapi as 'GROUP:BUILTIN\\Administrators'

SID prefix

CREATE USER root IDENTIFIED VIA gssapi as 'SID:S-1-5-32-544'  # usual SID form)

CREATE USER everyone IDENTIFIED VIA gssapi as 'SID:WD'  #well-known SID 2 letter prefix (WD=world, Everyone)

The lookup by SID was suggested by users in the above mentioned KB discussion, will perform slightly better, performance-wise, and won't need lookups in the AD. SID potentially can also be used with Unix kerberos, in case AD is used (i.e Linux or Mac join Windows domain) , there will be membership data in kerberos ticket in this case.

The GROUP: or SID: prefixes are case-sensitive, and there should not be any extra spaces in the string.

Implementation
The GROUP: prefix will cause need group name to SID transation (LookupAccountName, which can cause roundtrip to AD)
the SID: prefix will cause string SID to binary SID translation (ConvertSidStringToSid)

Once the SID is here, server impersonates the SSPI context,checks membership via CheckTokenMembership() API, then impersonation is reverted, and the returns result of the check as CR_OK or CR_ERROR

Note , that neither GROUP name nor SID need to be actual group in AD or local computer. It can be the name or SID of the user (this is just how CheckTokenMembership() works)

Note also, that CheckTokenMembership checks for ENABLED flags in current token groups. The practical implication is that to use "GROUP:Administrators in the UAC environment, client process must run elevated ("as Administrator")