elliptic-curve: `JwkEcKey` is too strict in what it accepts

[Erik1000]

As per RFC7517 section 4 (fourth paragraph)

Additional members can be present in the JWK; if not understood by implementations encountering them, they MUST be ignored.

But currently, if you try to parse this key for example (using the p256 crate; key created by step-cli):

{
  "use": "enc",
  "kty": "EC",
  "kid": "UYa89vgc4u_lpcbbmDQfYJQRAUD4AED8H8FUNjk5KyQ",
  "crv": "P-256",
  "alg": "ECDH-ES",
  "x": "hFc6OfbgRsYFOWyhGbWH0sS5DZBjJLGABJvPttVZfA4",
  "y": "tnXB8ks0-AZJKOgbMWJrE5Jm3nTFy0UiqQugmx9jku4"
}

It will fail, because it does not recognize the use parameter (it doesn't recognize some other parameters either, but that is the first parameter it sees). In fact, you have to reduce it to the following parameters (so only the ones from Field are present)

{
  "kty": "EC",
  "crv": "P-256",
  "x": "hFc6OfbgRsYFOWyhGbWH0sS5DZBjJLGABJvPttVZfA4",
  "y": "tnXB8ks0-AZJKOgbMWJrE5Jm3nTFy0UiqQugmx9jku4"
}

There's a registry for all key parameters at IANA but note that this list 1) may grow with new entries and 2) implementations are allowed to define custom parameters not in the registry.

My proposed solution would be to ignore unknown parameters just like the spec dictates it.