add basic support for client certificate to Quic

[wfurt]

This change as few separate parts:

1. We pay attention to ServerAuthenticationOptions.ClientCertificateRequired and we pass it to Quic as QUIC_CREDENTIAL_FLAG_REQUIRE_CLIENT_AUTHENTICATION.
   That has still two problems: It is ignored on Linux as well as on SslStream that is optional e.g. if client does not provide certificate it is possible to ignore that via custom callback but quick terminates the connection if client does not have cert.
   Contributes to HTTP/3: Support SslServerAuthenticationOptions with QUIC #49574

2. If client certificate is specified we would pass it to MsQuic on Windows.
   contributes to [QUIC] Use client TLS options in QUIC #32069

Once again, Linux is not supported yet.
SslStream has two mechanisms: Either once can pass it via collection of certificates and (over?)complicated process would select once candidate or this could be done via certificate selection callback.
I'm not sure if we could/should replicate the logic for QUIC. For now, we would simply pick first eligible certificate (e.g. X509Certificate2 with key). Feasibility of selecting certificate dynamically is till to be seen.

3. There is problem with passing ServerAuthenticationOptions to new connection on server.
   One can specify ServerAuthenticationOptions on QuicListener. But by the time new connection is accepted, the TLS handshake is already done and there is no good way how to pass options to it.
   To get ClientCertificte working, this PR will copy part of the options from Listener to new MsQuicConnection to inherit validation session. As part of that, we need Connection in state so we can lookup properties when validation runs. We would reset it afterwards to preserve current relation.

4. I wanted to do basic validation that the streams are useable as well as keep some of the objects alive to prevent premature disposal.
   I added helper test function to exchange simple message to validate that data can be sent and received.

cc: @nibanks @ThadHouse

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This change as few separate parts:

1. We pay attention to ServerAuthenticationOptions.ClientCertificateRequired and we pass it to Quic as QUIC_CREDENTIAL_FLAG_REQUIRE_CLIENT_AUTHENTICATION.
   That has still two problems: It is ignored on Linux as well as on SslStream that is optional e.g. if client does not provide certificate it is possible to ignore that via custom callback but quick terminates the connection if client does not have cert.
   Contributes to HTTP/3: Support SslServerAuthenticationOptions with QUIC #49574

2. If client certificate is specified we would pass it to MsQuic on Windows.
   contributes to [QUIC] Use client TLS options in QUIC #32069

Once again, Linux is not supported yet.
SslStream has two mechanisms: Either once can pass it via collection of certificates and (over?)complicated process would select once candidate or this could be done via certificate selection callback.
I'm not sure if we could/should replicate the logic for QUIC. For now, we would simply pick first eligible certificate (e.g. X509Certificate2 with key). Feasibility of selecting certificate dynamically is till to be seen.

3. There is problem with passing ServerAuthenticationOptions to new connection on server.
   One can specify ServerAuthenticationOptions on QuicListener. But by the time new connection is accepted, the TLS handshake is already done and there is no good way how to pass options to it.
   To get ClientCertificte working, this PR will copy part of the options from Listener to new MsQuicConnection to inherit validation session. As part of that, we need Connection in state so we can lookup properties when validation runs. We would reset it afterwards to preserve current relation.

4. I wanted to do basic validation that the streams are useable as well as keep some of the objects alive to prevent premature disposal.
   I added helper test function to exchange simple message to validate that data can be sent and received.

cc: @nibanks @ThadHouse

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Quic
Milestone:	-

[wfurt]

Since we agreed Dispose on stream should do the right thing, I think this should be ready for another review.

[ManickaP]

Small comment, otherwise LGTM. Thanks!