Consider creating a wrapper for hyperlight-host that locates sandboxes in remote processes

It should be possible to create a drop-in replacement for the hyperlight-host crate that exposes the same public API, but wraps the `UninitializedSandbox` and `MultiUseSandbox` types with wrappers that implement its calls via (optionally?) making RPCs to different processes. This might be useful for people who wish to run sandboxes in remote, low-privilege processes for even-more-defense-in-depth (e.g. against hypervisor kernel vulnerabilities), and might allow working around per-process resource limits.

This should be possible to do via a new crate which is a drop-in wrapper around the hyperlight-host crate, avoiding the need for any changes in Hyperlight itself.

Semantically, it also shouldn't require any changes to other crates that depend on hyperlight-host, like hyperlight-{wasm,js,unikraft}. Unfortunately, due to rust-lang/cargo#9227, there may be distribution challenges due to the inability to for a root crate to override `hyperlight-host` with some hypothetical `hyperlight-host-remote-process-wrapper` throughout the transitive dependency graph. The wrapper crate would either need to use `name = "hyperlight-host"` and be used as a git/path dependency, or hyperlight-{wasm,js,unikraft} would need to be made aware of its existence/configured to optionally depend on it.

Start by reviewing the public API of the hyperlight-host crate, especially UninitializedSandbox and MultiUseSandbox, and how hyperlight-wasm, hyperlight-js, and hyperlight-unikraft depend on it. Investigate the Cargo dependency and override constraints described in the issue. Done would mean a separate drop-in crate can preserve the API while locating sandboxes in remote processes without requiring changes to dependent crates.

Written by the indexing model from the issue text.