Allow specifying usages when importing public ECDH key, deriveBits/deriveKey refactor

[fhanau]

• Allow specifying deriveBits and deriveKey usages when importing public ECDH keys. This behavior is already supported when importing raw ECDH keys and is more intuitive even though the usages are not required for public keys, see comments.
• Create CryptoKeyUsageSet::derivationKeyMask() to include both derive operations
• Deletes two superfluous assertions in importEllipticRaw – the validation right afterwards is more thorough and provides better error handling.

Please let me know if you find anything unclear

[fhanau]

Opened an upstream PR with the same branch name.

[panva]

Please let me know if you find anything unclear

All import key formats that result (or may result) in a public CryptoKey are clear that that the usages array must be empty for the ECDH algorithm public keys.

This change makes something non-standard work on workers and not be portable to other runtimes. For a portable standard API that's very unfortunate.

[jasnell]

Ah, right, I'd forgotten that detail. This is definitely something we should reconsider. /cc @fhanau @dom96

[fhanau]

Please let me know if you find anything unclear

All import key formats that result (or may result) in a public CryptoKey are clear that that the usages array must be empty for the ECDH algorithm.

This change makes something non-standard work on workers and not be portable to other runtimes. For a portable standard API that's very unfortunate.

You're right, I missed that aspect of the specification. I'll work on fixing this.