Centralize WasmModule parameters into a Config struct

[jtakakura]

Problem

Currently, WasmModule uses multiple load* functions with many positional arguments. This makes the API hard to maintain and expand. Also, because parameters like deadline or max_memory are set after the module is loaded, we cannot apply these limits to the start function that runs during the loading process.
This refactoring is a prerequisite for implementing execution cancellation (#27) to ensure consistent flag propagation and prevent further API bloat.

Proposed Solution

Introduce a WasmModule.Config struct in src/types.zig and refactor the loading pipeline.

1. Define WasmModule.Config: Group all instantiation and execution settings into a single struct with default values:

pub const Config = struct {
    wasi: bool = false,
    imports: ?[]const ImportEntry = null,
    fuel: ?u64 = null,
    deadline_ns: ?i64 = null,
    max_memory_bytes: ?u64 = null,
    force_interpreter: bool = false,
    wasi_opts: ?WasiOptions = null,
};

2. Unify loading logic:
   • Change loadCore to accept this Config struct.
   • Keep loadCore private and provide a clean public API: loadWithConfig.
3. Update callers: Refactor c_api.zig, cli.zig, and tests to use the new struct-based API.

Alternatives Considered

Setting limits after load: This is simple but fails to protect the start function execution.
Builder pattern: Structs with default fields are more idiomatic in Zig.

Scope

This issue is refactor-only. No behavioral changes are intended.

Non-goals

Implementing cancellation logic itself is out of scope and will be handled in a separate issue/PR.

Acceptance Criteria

1. WasmModule loading APIs are unified via Config-based entrypoint.
2. VM limits/options in Config are applied before start function execution.
3. Existing tests pass without regression.
4. Legacy load APIs are either removed with callsite migration or kept as thin wrappers with deprecation notice.