Add support for checkpointing memory-backed tmpfs mounts.

[copybara-service]

Add support for checkpointing memory-backed tmpfs mounts.

This extends runsc fscheckpoint --path=all-tmpfs to also checkpoint tmpfs
mounts backed by the shared/main MemoryFile (e.g. Kubernetes emptyDir volumes
with medium=Memory), in addition to the disk-backed tmpfs mounts already
supported.

These mounts were previously excluded because their file contents live in the
sandbox-wide main MemoryFile alongside all application memory, so there was no
way to checkpoint only a single filesystem's pages without saving everything.

This change adds that ability:

• ResourceIDs are now assigned to every tmpfs filesystem created from the OCI
  spec, stored on the filesystem itself rather than on its MemoryFile. This
  lets save/restore identify and key these filesystems even when they share the
  main MemoryFile (which has no ResourceID of its own), and naturally excludes
  tmpfs mounts created by the application mount(2), which get no ResourceID.
• On save, instead of MemoryFile.SaveTo (which saves a whole MemoryFile), the
  pages owned by each such filesystem's regular files are written directly to
  the pages file via new pgalloc APIs (AsyncPagesFileSave.RegisterMemoryFile
  and AsyncMemoryFileSave.WriteRange). The pages are read straight from the
  main MemoryFile with no intermediate copy, and the tar archive records the
  resulting pages-file offsets instead of MemoryFile offsets.
• On restore, the main MemoryFile is freshly created and is live application
  memory, so the saved offsets cannot be reused. Instead the contents are
  relocated: tmpfs allocates fresh pages in the main MemoryFile and loads the
  saved contents into them via the new AsyncPagesFileLoad.LoadRangesInto,
  remapping each regular file's data to the newly-allocated offsets.

Disk-backed tmpfs mounts continue to be saved/restored verbatim (whole private
MemoryFile via SaveTo/LoadFrom); the new path is used only when a filesystem is
backed by the main MemoryFile.