Snapshot follow up items #1479

The following items are follow up items after #1459 was merged

• Rename hostfunctions.hostfunctinos field Create sandboxes directly from snapshots #1459 (comment)
• document gdb lifecycle Create sandboxes directly from snapshots #1459 (comment)
• Make sandboxes from the same snapshot/disk restore-compatible (i.e. remove sandbox_id field, hash, with proper verficaiton) Create sandboxes directly from snapshots #1459 (comment)
• Have separate configs for creating sandboxes from scratch and from snapshot, to avoid ignored fields
• Think harder about sematincs of mutable host functions (allow registering after sandbox is created, and create sandbox with set of host functions that is superset of hostfunctions that existed at snapshot-time.

After #1465 is merged, we also have the following items

• Support multi-layer OCI snapshot (map scratch? Determined by benchmarks) #1551

• Support core dumps for sandboxes created from snapshots #1617

• max_guest_log_level is not plumbed through snapshot load.

• The backing OCI directory must not be modified, truncated, renamed over, or deleted for the lifetime of a loaded Snapshot or any MultiUseSandbox built from it. On Linux this is unenforced. On Windows the OS refuses the operation with ERROR_USER_MAPPED_FILE (1224). Firecracker has the same constraint:

  The memory file (pointed by backend_path when using File backend type,
  or pointed by mem_file_path) must be considered immutable from
  Firecracker and host point of view. It backs the guest OS memory for read
  access through the page cache. External modification to this file corrupts
  the guest memory and leads to undefined behavior.

  firecracker docs

• Typed error variants

• Investigate Cross-hypervisor portability

• Huge page support

• "Golden snapshot" testing for checking ABI breaks

• Atomic file operation for crash safety (load/save snapshot to disk)

• Consider adding convenience method MultiUseSandbox::from_oci (or not)

• Docs / examples for how to use with Oras/etc etc