Allow applications to pick their C_x

[chrysn]

Applications may need to pick their own C_x (as opposed to the EDHOC library picking one at random, as it was before) for three reasons:

• The library doesn't manage the set of contexts, so it can't know which C_x are already in use and which are not.
• The C_x may be used for other purposes (eg. OSCORE contexts), and might be namespaced there, which also only the application may know. (Silly example, but the application may use the OSCORE context identifiers that correspond to negative C_x for use with ACE-OSCORE profile, and only those with positive C_x for EDHOC).
• When processing of message 1 and creation of message 2 are split over time (as is necessary when implementing an EDHOC server on the coap-handler interface), it is practical to already decide on a C_R at processing time, store the responder, and dig it up when creating the response -- but that requires the C_R to be decided already at storing time.

This will likely need follow-ups for similarly delegating the choice of {ID_,}CRED_peer to the callers (resolving #99 issues from), but those are separate enough that I'd do them in a separate PR.

These are API breaking changes. They're split in two because I did C_R first, and kept them split to ease review especially on the CI side; when ACK'ed, I'd like to squash them.

[geonnave]

Thanks @chrysn, it looks good. Left a minor comment. As for merging, maybe we could merge it directly into the remove-hacspec branch I just pushed upstream.

[chrysn]

This is now only one commit atop #106. Rebasing was a bit of a hassle, but worked in a mixed cherry-pick and manual application approach. Looks like remove-hacspec is in a stable enough shape to rebase onto, at any rate, and things are much easier on that!

From my PoV, this is done once CI says Go.

[geonnave]

Great! Merged into remove-hacspec.