parse_ccs fixes

[chrysn]

parse_ccs is very lax right now, and that can cause great confusion: when sending a key in an unexpected format, a panic may happen deep inside p256 / subtle, around public keys being not a good point. (We should catch that panic either way, but this had sent me to the completely wrong track).

This adds a test for whether the parsing function rightfully errs out on stuff it doesn't recognize, and rewrites the parsing so that it does err out.

[chrysn]

Two notes on the function's behavior, apart from the obvious new rejection of "malformed" items:

• It does accept longer KIDs now, simply because I'd have to go out of my way not to.
• It does not yet come down hard on invalid-length y coordinates, a) because they're not processed any further, but b) also because I cheated in earlier experiments and put y='' in to accommodate for credential-by-value space constraints. (On the long run, we should reject wrong y values, but maybe we should consider whether we regard y as optional, especially given that at least the credentials we're using now are only used for ECDH where the y doesn't matter).

[chrysn]

The panicing is already tracked in #93, and there's a note in the code on it around

lakers/crypto/lakers-crypto-rustcrypto/src/lib.rs

Line 118 in e1561d6

// While this can actually panic so far, the proper fix is in

[geonnave]

Looks good, thanks!