Remove EC_KEY from S.S.Cryptography.Native API

[krwq]

Starting from #104961 we don't really need to keep dependency on EC_KEY anymore and can base all Import/Export APIs solely on EVP_PKEY.

There are couple of advantages of doing this:

• most notably Import/Export APIs become much less chatty on the P/Invoke boundary
• we move away from old OpenSSL APIs
• we can reduce a bit of code (i.e. remove SafeEcKeyHandle - see notes)

Some notes:

• for full advantage we would need to deprecate IntPtr overloads from (ECDsa|RSA|ECDiffieHellman)OpenSsl - there already exist SafeEvpPKeyHandle which can fully substitute it but it requires some work on the caller

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[bartonjs]

I updated the title to say something closer to the definition of success being removing EC_KEY* from the exported functions signatures.

If we can fully get rid of it, great/fine. But if we still need it to power the import/export APIs on the native side, that's still better than the export/import APIs being in terms of EC_KEY itself.

[krwq]

I'm changing this to be milestone 10.0 because it seems you can no longer use these APIs with providers on newer versions of OpenSSL (EVP_PKEY_get1_EC_KEY seem to be always returning invalid handle). I'm definitely observing this when investigating #111251 - I have not yet made any changes but seems that EC related tests are all failing on the Export step and I could not find any changes on our sides which could have contributed to this.

[krwq]

We decided that removing EC_KEY fully is out of scope for now because that would mean ECDsa/ECDH will stop working on RHEL 8 which only supports OpenSSL 1.1. We'll need to support both scenarios. I'll start plumbing export code as part of #111251 to make provider scenarios work correctly - we will fallback to new APIs when we can't get EC_KEY from EVP_PKEY (mixing one and the other is not working well on newer versions of OpenSSL therefore as long as import is based on EC_KEY that seems to be preferred way so that we don't fallback in most typical scenario). I'll also share my working copy of the export/generation code here but it's not fully functional yet so will need a bit more work but it should be close to the good state. At one point we can switch the fallback into preferring new APIs and falling back to old ones and then once OpenSSL 1.1 is fully deprecated in X years we can remove that old code completely.