[client certificate]: support Subject Name + Issuer authentications

[yugangw-msft]

Minimum change. Naming and logic are chosen based on dotnet version.
Once the mechanism is approved, i will add test coverage

[rayluo]

Documenting some offline discussion here.

• To generate key pairs, you can use openssl, e.g. openssl req -x509 -nodes -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
• For what it's worth, the jwt.encode({...}, a_combined_key, ...) we used also accepts a private+public combined key file, and it will choose the private to do the encoding. However we decide to keep the private key and public key as 2 separated input parameter from the beginning, rather than relying on external logic to extract the public key from the combined input.
• The agreed naming public_certificate (rather than send_x5c) was also proposed before in ADAL .Net

This PR looks straightforward! Thanks @yugangw-msft ! Feel free to "add test coverage" (as you mentioned in PR description). I'm sending the PR review approval right now. :-)

[yugangw-msft]

@rayluo, test coverage is added. Feel free to merge when this gets approved
//CC @mbearup

[rayluo]

Also documenting the backgroud of this SubjectName/Issuer Authentication feature. The workflow would look like:

1. Update AAD tenant to accept approved issuers – this is outside the scope of this PR.

   • The AAD Tenant only accepts certain issuers (AME) which have strict association of subject name and requestor

2. User associates an issuer/subject name with their service principal – also outside the scope of this PR.

   • Once I as the requestor register contoso.com with AME CA, no one else can get it.
   • This is the foundation of SN/Issuer trust. Rather than trusting the thumbprint, you’re trusting that the CA vouches for me as the only one who can generate certs for that subject name.

3. User configures app to use SNIssuer auth instead of thumbprint-based.

   • We don’t need to deprecate thumbprint auth or switch back and forth. The client would simply use a different login option going forward, e.g. az login --newoption /path/tocert
   • As the requester/user it’s still my responsibility to get the latest pfx from keyvault/dsms/etc. An expired cert would still be rejected by AAD.
   • What this saves us is the trouble of registering a new thumbprint with AAD, which would create a more complex autorotation scenario (use old cert to register new cert, then use new cert to deregister old cert).
   • Without SN/Issuer auth there is also a gap in authentication when key material is rotated. When KeyVault issues a new cert, its thumbprint is not in AAD. My app would have to recognize this, rotate thumbprints in AAD, and try again.
   • Note that the key material does get rotated, but that’s not what is being trusted. Instead we’re trusting that an approved CA issued a cert with an approved subject name and that we have the matching private key for that cert.
   • With SN/Issuer auth the only thing I have to worry about is getting the latest pfx for my app.

[navyasric]

Looks Good.