Constant bitstrings in atoms (for bit-level fuzzing) -- Attempt with Codec::read_bytes

[LCBH]

The intended goal of this PR (still WIP) is to add a new kind of atom (actually a variant of a Term::Variable) corresponding to constant bitstrings amenable to bit-level fuzzers. The real challenge is to make this work with the current dynamic functions architecture operating on Box that are first dynamically type-checked against the expected type shapes of the arguments. See dynamic_function::make_dynamic and the dynamic_fn macro.
For this, we expose the Codec traits for all arguments of the dynamic functions in the signature. This way, we can dynamically re-interpret bitstrings as proper messages handled by the function symbols in the signature using Codec::read_bytes.

Problem 1: in tlspuffin, all structs corresponding to data handled by function symbols have the Codec trait, except
derived structs like Vec<handshake::ClientExtension>, handshake::ClientExtension has the Codec trait though.

\error[E0277]: the trait bound `for<'a, 'b> fn(&'a Vec<handshake::ClientExtension>, &'b handshake::ClientExtension) -> Result<Vec<handshake::ClientExtension>, FnError> {fn_extensions::fn_client_extensions_append}: DescribableFunction<_>` is not satisfied

--> it should be possible to simply derive Codec for those as well.

Problem 2: in the current architecture, the dynamic functions operates on pointers to their arguments (since they exist
in the orginal terms anyway). However, we now need to dynamically compute <typeShape_arg>::read_bytes(bitstring) and
we would need some sort of "owning reference." Again, this should be fixable.

Problem 3: this is a fundamental issue with this approach (see first item of the "Pros" from [#279]). Since we need to be able to compute <typeShape_arg>::read_bytes(bitstring)
for all bitstrings post-mutations, we may reject mutations on the basis they crash the parsing by rustls, while the possibly more
permissive and buggy PUT parsing routine may accept it. It is still possible to bit-level mutate a larger term
containing the current one but then we loose the structure of other sub-terms we may not be interested to bit-level mutate.
--> To be able to bit-level mutate whole sub-terms without being rejected by the Mapper failures, we must adopt another strategy explained in [#279].