MIR: UNPACK instruction

Context

Adds UNPACK instruction.

Part of: #6626 (closed)

Based on: !11194 (merged)

Some design notes:

Implemented via a pretty run-of-the-mill recursive descent parser, because nothing more involved is required here.

BytesIt is introduced for simplicity (and avoiding allocations), Iterator<Item = u8> doesn't quite fit, because we need to chomp exact number of bytes (take will produce at most the requested number, which is not what we want), and producing variable-length slices from Iterator would require allocations.

Extra care is taken to avoid unnecessary allocations in the common cases, to that effect SmallVec with a sensible on-stack buffer is used for variable-length fields. This wastes some on-stack memory, but this shouldn't be an issue. One kink is annotations are still always-allocating, amending this is left for future work (TL;DR: using SmallVec in Annotations messes with variance in unexpected ways, so will need to roll our own; thankfully, for the common case of one annotation per primitive -- e.g. entrypoints, EMIT -- this is very straightforward)

BigInt parser is reimplemented, as going through Zarith is more involved than it's worth. The code is loosely based on the one from tezos_data_encoding.

There's an unforeseen interaction with lambdas (and how they carry raw Micheline around): unpacking requires allocating Micheline long-term, which means interpreter needs access to an arena. Chucking it into Ctx doesn't quite pan out due to borrow checker (also, it doesn't quite match the lifetime semantics of the tzt runner), so it's passed around the interpreter via an extra argument. This unfortunately complicates the API, but amending that here is out of scope, and we don't really have time for an API redesign at this point.

Manually testing the MR

cargo test

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR