Use GSS_C_NT_HOSTBASED_SERVICE, not GSS_KRB5_NT_PRINCIPAL_NAME

Using `GSS_KRB5_NT_PRINCIPAL_NAME`, and setting the realm to anything other than the empty realm, is a recipe for failure in multi-realm environments.

For example, today I had to debug a case involving three realms, let's call them `AD.FOO.EXAMPLE`, `FOO.EXAMPLE`, and `N.FOO.EXAMPLE`, where on a Linux system `[libdefaults] default_realm = N.FOO.EXAMPLE`, and the SQL Server's principal really is `MSSQLSvc/someserver.ad.foo.example@AD.FOO.EXAMPLE`, but `mssql-cli` constructed a raw Kerberos principal name of the form `MSSQLSvc/someserver.ad.foo.example@`, i.e., `MSSQLSvc/someserver.ad.foo.example@N.FOO.EXAMPLE`. The client credentials we for `user@AD.FOO.EXAMPLE`...

What happened then was that the client fetched a cross-realm TGT, `krbtgt/N.FOO.EXAMPLE@FOO.EXAMPLE` then asked a KDC for `N.FOO.EXAMPLE` for a service ticket for `MSSQLSvc/someserver.ad.foo.example@N.FOO.EXAMPLE`, which yielded a referral to `FOO.EXAMPLE`, which then rejected the request because it would mean doubling back to `AD.FOO.EXAMPLE`, which would be a loop.

Constructing an alternate `krb5.conf` with `[libdefaults] default_realm = AD.FOO.EXAMPLE` and using it by setting the `KRB5_CONFIG` environment variable worked around the problem by causing `mssql-cli` to construct the correct service principal name, `MSSQLSvc/someserver.ad.foo.example@AD.FOO.EXAMPLE`.

If `mssql-cli` had either use `GSS_C_NT_HOSTBASED_SERVICE` and `MSSQLSvc@someserver.ad.foo.example`, or `GSS_KRB5_NT_PRINCIPAL_NAME` and `MSSQLSvc/someserver.ad.foo.example@` (note the "empty" realm), then it would have worked without us having to work around it.