Support long C_x

[chrysn]

Closes: #258

This is a straightforward change and relatively complete; noteworthy points are:

• On some parts that I don't usually touch, things were not changed -- they should keep working, but they may still only support the short identifiers.
  Grep for from_int_raw to see all possible places; in particular, I known of the C API, and of the automatic generation of identifiers.
• There are unit tests in the docs, and I enabled the previously disabled tests that planned ahead for this and things just do check alright. There are no new integration tests, but I don't know whether we need any. I tested things from aiocoap, and things worked fine; I can still try an interop test with Marco later this week.
• The backing data for identifiers is an interesting thing because it's an owned small array that has no length information. CBOR is self-delimited, and I'm making use of that, thus fitting the 7 byte sensible string length (typical OSCORE KIDs are up to 7 byte) in 8 byte of RAM. The type describes its invariant, and explicitly panics in a place. I'd guess that that's just one of the panics where hax could show that no safe operation on that type will ever get it in a state where that invariant is violated, but I know too little about it to tell whether it already does that, or whether it'll need some handholding, or whether it doesn't matter anyway.

[chrysn]

I had to add one more fix where we used .as_slice() instead of .as_cbor() (which made no difference so far), and now interop'd with Marco with aiocoap/lakers as the initiator (producing both short and long C_I) and Marco as responder (producing both b'' and numeric C_R).

Please review.

[geonnave]

Thanks for this PR! I went through and actually have no extra comments. Merging.