Review of the original DevPod providers (not all of which are forked here) shows that:

• some (aws, civo, azure) prepend all their options with provider flavor (AWS_, CIVO_, AZURE_);
• some (digitalocean, gcloud, ssh, terraform, dockerless, ecs) do not;
• kubernetes provider prepends four of its options (NAMESPACE, CONTEXT, CONFIG, PULL_SECRETS_ENABLED), but not others.

This is inconsistent - and should be made consistent.

There seems to be no reason to have option names prepended with the provider's flavor: after all, they are used with a specific provider, and are thus already conceptually scoped by it.

Current implementation names environment variables used to convey the options to the provider exactly the same as the options they carry.
If a possibility of an option's environment variable with too generic a name (USER, HOME, etc.) colliding with pre-existing environment variable is a concern, instead of mangling user-visible option names we should use devpod-scoped environment variables to carry the option values to the provider, for example: rename AWS_DISK_SIZE option to simply DISK_SIZE, and use environment variable DEVPOD_PROVIDER_AWS_DISK_SIZE to carry it internally.