Feat: enable configurable default disk capacity for native and builder containers

[karenheckel]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

• Fixes [Request]: Storage - Add configuration for default container disk capacity #887
• This change adds support for specifying a default disk capacity. This allows users to define global storage defaults without needing to pass --storage each time they run a container. It aligns disk capacity behavior with the existing CPU and memory default configuration.
• Added rootfs.storage to the system property configuration.
• Added validation logic to ensure the user-specified capacity does not exceed available host space.

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

[jglogan]

Thank you for contributing! I've left a couple of questions and minor change requests in the comments.

[jglogan]

@karenheckel AFAICT I see one test failure:

◇ Test testBuilderStorageFlag() started.
✘ Test testBuilderStorageFlag() recorded an issue at CLIBuilderLifecycleTest.swift:73:17: Expectation failed: (abs(reportedMiB - expectedMiB) → 511968) <= (tolerance → 409)
↳ expected root filesystem size ≈ 4096 MiB for storage 4096MB, got 516064 MiB

[karenheckel]

@jplogan We have the plumbing set up for configuring the disk storage. However, we think that the underlying container runtime ignores the resources.storage field since the Containerization backend isn't wired to it yet, so the VM still boots with the default disk image size. A follow-up PR could extend the VM layer to actually size the rootfs block device according to resources.storage.

If there is something we are not understanding correctly, please feel free to let us know!

[karenheckel]

@jglogan We have attempted to provide backend support for the storage configuration support. Here is that pull request. The frontend (this PR) works, but the backend hasn't fully worked locally. If you have any suggestions, we would love to hear them. Thank you!