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.