The implementation limits for JS embedders at [1] describe various upper
bounds for entities in Wasm modules, including the size of a single
function body in bytes. wasmparser is not strictly required to abide by
these implementation limits because they are conventions for the JS
embedding of Wasm rather than part of the core Wasm standard. However,
it does seem to enforce other limits, such as the number of types or
locals; this PR updates it to enforce function body size as well.

This came up in bytecodealliance/wasmtime#11682, where a very large
function (larger than the implementation limit) led to out-of-bounds SSA
value numbers in Cranelift when they exceeded the range allowed by our
data-structure bitpacking. Rather than doing major surgery to plumb the
exact failure through all of Cranelift (including its public API being
`Result`-ified on every builder interface) it seems better to have a
single limit on the size of incoming functions. It turns out that the
Wasm implementation limits were designed for just this purpose, so let's
use them in our tooling as well.

[1]: https://webassembly.github.io/spec/js-api/#limits