Add opt-in parser limits for untrusted modules

[matthargett]

Related to #66. TinyWasm's default validator limits are deliberately broad for general WASM. For host that loads untrusted guest programs, a small binary can still encode disproportionate parse work (like a large local declaration or array.new_fixed count).

This adds opt-in ParseLimits to ParserOptions for encoded module bytes, entries per section, parameters plus locals per function, br_table targets, and array.new_fixed elements. Byte, file, and stream entrypoints share the input limit; streaming counts total bytes read even when its buffer slides. The two operator fanouts are checked before wasmparser validation and lowering. Compact-import expansion is counted before validation when the section limit is set.

All limits default to unlimited. The ordinary parser path and interpreter dispatch are unchanged; hosts that enable operator fanout limits take a guarded parser-only decode path. Validation should remain enabled for untrusted modules. These are input and known-amplification limits, not a hard peak-memory or elapsed-time guarantee: wasmparser can allocate while decoding a recursive type group before TinyWasm checks its expanded size.

With limits in place, some pathological .wasm files now get properly rejected on my Apple Watch test app, instead of the app crashing.

Local Mac validation: 50,000 deterministic fuzz mutations of adversarial parser fixtures. I also looked at guard techniques from other WASM parsers/runtimes test suites and rolled some of those tests in.

[explodingcamera]

thanks for the pr! Sounds very reasonable, I'll just push a small follow up commit simplifying some of it.