shared: Add feature to simply enlarge buffers

[chrysn]

This does not do away with the need for better control over the shared library's buffer sizes, but merely provides a band-aid through which sending credential-by-value works with non-near-zero subject sizes.

A proper and full solution may need a lot of further discussion (like, use generics? flags?), but this at least ensures that Python users (which are generally not too limited on memory) don't run out of space while experimenting.

[chrysn]

This should also take pressure off during testing; for example, in https://github.com/openwsn-berkeley/lakers/pull/279#discussion_r1609719730, a temporary change sneaked into a commit. We currently don't even have examples of sending credentials by-value because not all but at least the test vector credentials are too large to send.

[geonnave]

I agree we need something in this direction. Please also note that #284 is introducing a new EdhocBuffer type with const generics so we can at least have a finer control over buffer sizes (we will probably expect some to be potentially larger than others, for example Credential and Message buffers may need to be quite large, while buffers for variable-size kids should not be too large).

[chrysn]

Fixed the C issue.

Yeah, I think that generics will be the way to go from here; either as numeric parameters, or even by accepting any AsMut<[u8]> (or something similar) such as [u8; N] or Box<[u8]>; but that may take some more time to mature.