Implement linear fees (a + bx) for aggregate instructions

[nagisa]

This has adjusted the finite-wasm analysis and instrumentation to collect fees not as constant values for each operation, but in form of a + bx. However, using linear fees extensively is not recommended, as fees that have b ≠ 0 are not mergeable and will incur a significant instrumentation overhead.

As a future change it may be possible to still merge some instances where b ≠ 0, but since a lot of care will be necessary to make sure that x stays the same, merging logic will need to be somewhat more complicated than it currently is.

Even then, since all of the bulk_memory operations for which linear fees are useful are trapping merging across the instruction is not applicable at all.

This has required somewhat extensive changes to the interpreter we use in our specification as well as to our test runner to allow for situations where the aggregate instruction may trap in the middle of its execution. In particular, say, memory.copy may trap after processing 5 elements (thus charging 5 gas according to the reference interpreter,) but at instrumentation level we only have an instruction-level granularity available, so we must pre-charge gas assuming the entire operation would succeed. This means that the actual gas consumption observed from the interpreter can be anywhere between gas_before_aggregate <= gas_before_aggregate + steps if a trap occurs.

Recommended review strategy is to look at the "implement linear fees for aggregate instructions" in isolation and only skim the 2nd commit to verify instrumentation changes appear sane. Reminder that users aren't required to use instrument.rs module in production and neither does nearcore (though not for wasmtime...) -- they can get by with just analysis results and introduce instrumentation directly into the generated machine code.

Based on top of https://github.com/near/finite-wasm/pull/78 Fixes https://github.com/near/finite-wasm/issues/49