Draft: add opt-in generic WebAssembly execution backend

[bkmashiro]

Summary

This PR adds an opt-in generic WebAssembly execution backend for Shimmy.

The new backend is enabled only when:

FUNCTION_INTERFACE=wasm

Existing rpc and file execution paths remain the default behavior and continue to require FUNCTION_COMMAND.

The WebAssembly path loads a pre-built .wasm evaluator module through wazero, keeps a warm instance pool, and restores a memory snapshot after each request so guest-side mutable state does not leak between evaluations.

What is included

• Adds wasm as an opt-in execution interface.
• Adds a small host ↔ guest adapter ABI:
  • exported memory
  • exported alloc
  • exported evaluate
• Adds a wazero-backed dispatcher/supervisor implementation.
• Adds snapshot/restore support for WASM linear memory.
• Adds tests for:
  • dispatch lifecycle
  • memory snapshot restoration
  • failed startup cleanup
  • Go/Rust/C++ artifact examples
  • Go/Rust/C++ package-shaped evaluator examples
• Adds demo scripts for running WASM-backed evaluators through Shimmy HTTP endpoints.

Scope / non-goals

This PR intentionally keeps the first WASM backend small and generic.

It does not attempt to migrate existing Lambda Feedback Python evaluators, Pyodide, Lean, Wolfram, Node/TypeScript, or other runtime-heavy evaluators.

The examples in this PR are synthetic Go/Rust/C++ evaluator artifacts used to validate the execution backend and packaging shape. They are not presented as migrations of existing LF evaluator repositories.

Python/Pyodide-style runtime packaging should be handled as a separate follow-up profile once the generic artifact backend is reviewed.

Backwards compatibility

The existing production paths should remain unchanged:

• Default interface is still rpc.
• rpc and file backends still require FUNCTION_COMMAND.
• The new WASM backend is only selected with FUNCTION_INTERFACE=wasm.
• Existing worker process behavior is not replaced or auto-routed to WASM.

In other words, this PR adds a new opt-in backend rather than changing the default evaluator execution model.

Testing

Locally verified:

go test ./internal/execution ./internal/execution/wasm
go test ./...
./scripts/demo-wasm.sh
./scripts/demo-cpp-wasm.sh
git diff --check

The demo scripts verify that multiple HTTP requests can hit a warm WASM evaluator while guest global state is reset after each request.

Example observed behavior:

• first request: guest_invocation_count = 1
• second request: guest_invocation_count = 1

This confirms snapshot/restore isolation for the demo evaluators.

Notes for reviewers

The most important review areas are probably:

• whether the alloc / evaluate adapter ABI is acceptable as Shimmy's internal WASM ABI;
• whether FUNCTION_WASM_MODULE vs FUNCTION_COMMAND compatibility is the right deployment shape;
• whether the generic backend should land separately from the example directories;
• whether any additional guardrails are needed before enabling this in production deployments.

I am opening this as a draft first.