Allow snapshot-backed `SandboxBuilder` to accept a complete `SandboxConfiguration`

[simongdavies]

Problem

Hyperlight-JS stores construction settings in a SandboxConfiguration. Its fresh-sandbox path forwards that configuration to Hyperlight, but its snapshot restoration path discards it and creates a hyperlight_host::SandboxBuilder::from_snapshot() using Hyperlight defaults.

This loses any configured non-structural construction settings available for the current platform and feature set, including interrupt configuration, per-sandbox crashdump enablement, and GDB configuration. These settings cannot be changed after the restored MultiUseSandbox is built.

Hyperlight's snapshot builder exposes per-field methods for these values, so Hyperlight-JS could separately retain and replay every setting. However, that would duplicate Hyperlight's configuration state, require wrapper changes whenever settings are added, and cannot reconstruct fields whose SandboxConfiguration getters are not public.

The snapshot builder should therefore accept a complete SandboxConfiguration. Hyperlight's existing low-level restore semantics should remain unchanged: snapshot-owned heap, scratch, and transport geometry override caller values, while non-structural construction settings come from the restoring host.

Proposed API

let sandbox = SandboxBuilder::from_snapshot(snapshot)
    .sandbox_configuration(config)
    .build()?;

Snapshot-owned structural values are still applied. Other restorer-owned settings should come from the supplied configuration.

Maybe we should split the configuration into 2 different structs to make this cleaner