Add WebCrypto ECDSA support for the secp256k1 curve

[ibremseth]

Adds namedCurve: "secp256k1" support to WebCrypto ECDSA, gated behind the new secp256k1_ecdsa_curve flag.

BoringSSL doesn't implement secp256k1, so this uses libsecp256k1 (Bitcoin Core's reference implementation). raw and jwk formats work, plus sign/verify/generateKey. ECDH over secp256k1 is rejected explicitly.

Follow-ups:

• Keccak-256 (waiting on implement a subset of "Modern Algorithms in the Web Cryptography API" #6403)
• SPKI / PKCS8 import/export.

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[panva]

I'm not aware of any extension to Web Cryptography that defines these.

https://w3c.github.io/webcrypto/#extensibility
Vendor-specific proprietary extensions to this specification are strongly discouraged. Authors must not use such extensions, as doing so reduces interoperability and fragments the user base, allowing only users of specific user agents to access the content in question.
If vendor-specific extensions are needed, the members should be prefixed by vendor-specific strings to prevent clashes with future versions of this specification. Extensions must be defined so that the use of extensions neither contradicts nor causes the non-conformance of functionality defined in the specification.

[kentonv]

I guess this is the same as #6689 except using a different dependency library. My comment there applies here too. We need a higher-level product discussion about whether this is a direction we want to take, before landing an implementation.

[ibremseth]

Closing in favor of: #6689