Support chunk-based regular files in EROFS
gVisor rejects EROFS images that use the chunked-file feature, so ordinary images built with mkfs.erofs --chunksize fail to mount. This change proposes to support single-device chunked files, using either the 4-byte block map or the 8-byte chunk index.
Rather than adding a second read path, it replaces DataOffset and DataRanges with Inode.MapBlocks, which follows Linux's erofs_map_blocks. Given a file offset, it returns the extent that holds it for flat, inline, and chunked inodes alike, so reads and mmap go through the same code. It also merges neighboring chunks that are contiguous in the image or are all holes, and like Linux it only scans one block of the chunk map per call.
Holes read as zeroes, and when they're mapped they point at a read-only page of the application memory file, much like Linux's DAX path maps the zero page. The filesystem allocates that page at mount and frees it along with the filesystem, so it's saved and restored with the rest of application memory, and private writable mappings still copy on write as usual.
The containerManager.Mount RPC now uses the kernel's supervisor context instead of context.Background, because a chunked image needs the application memory file at mount time.
This includes the fix from #15525, because reads and mmap now share one path, so whichever of the two merges first, I'll rebase the other onto it.
FUTURE_COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/15527 from shayonj:shayon/erofs-chunked-files 8c00a019e1ca519b4ba6f476878e690f7bf70fd6