Technical design: Wasm bytecode validation and analysis

Not all bytecode is equal.

- Some bytecode may be illegal to run; such bytecode must be rejected.
- Some bytecode may be unsafe to run if it uses non-deterministic Wasm features (e.g. threads, floats, etc.)
- Some bytecode may be costly to link if it imports a ton of elements (e.g. syscalls).
- Assuming bytecode size correlates with executable code size, some actors will require more memory just for the program than others.
- Some bytecode may be more expensive to compile and/or execute than others (thus potentially leading to JIT bombs).

Goals are:

- Reject invalid bytecode or bytecode that does not satisfy our constraints.
- Compute complexity factors during the bytecode validation and analysis during installation.
- Compute complexity factors for the subsequent instantiation act (to be memorized and applied every time an actor with this code is invoked)
- Price both acts with installation gas and invocation gas.
- Storage gas: we will already charge for bytecode storage, but need to account for compiled module storage (and potentially multiple versions of it!)

No files, tests, or entry points are named. Start by turning the validation, complexity, gas-pricing, and compiled-module-storage goals into an agreed technical design; completion is not defined beyond addressing those goals.

Written by the indexing model from the issue text.