[v6] Replace elliptic.js with noble-curves, and load noble-hashes dynamically

[larabr]

Unlike elliptic.js, noble-curves targets algorithmic constant-timeness (close #720).

With these changes, both noble-curves and noble-hashes are loaded dynamically, meaning they are not included in the main bundle of the lightweight build.
This results in considerable bundle size optimizations, since these libs rely on the large BN.js lib when native BigInts are not available.

TODO:

• merge after Ed448 PR.

[twiss]

This is very nitpicky but it would be clearer as:

Suggested change

	const { publicKey: V, privateKey: v } = await curve.genKeyPair();
	// The output includes parity byte
	const rawSharedSecret = nobleCurve.getSharedSecret(v, Q);
	return { publicKey: V, sharedKey: rawSharedSecret.subarray(1) };
	const { publicKey, privateKey } = await curve.genKeyPair();
	const rawSharedSecret = nobleCurve.getSharedSecret(privateKey, Q);
	const sharedKey = rawSharedSecret.subarray(1); // Remove parity byte
	return { publicKey, sharedKey };

(we might also want to rename Q, but doesn't need to be done here).

[larabr]

I'd avoid "privateKey" and "publicKey" because they are confusing in a context where we also have long-term private and public keys (e.g. Q).
The letters are convenient to follow what's going on, e.g. vQ === vdG === dvG === dV, and they are commonly used (e.g. see X25519 RFC).
Since we already have params named d and Q, I think switching to different names here is confusing, as the function is not generic.
If we really want to rename, I'd go with longTermKeyPair vs ephemeralKeyPair. But in a separate commit, so that it's clearer how the values map to the old ones with the lib switch.

[twiss]

OK, fair enough. Yeah, I'd prefer to have more descriptive names but indeed we can do it separately 👍