FR: support composing multiple active profiles

[gaojunran]

My use case: define some profiles like interfaces in Java or trait in Rust, and activate them in one time. For example, I may have a profile called server, which is only activated in my cloud server, and a profile called action, which is only activated in my github action server. They may have intersections or not.

I'm not sure if my use case is common. I'm ok if this is rejected, or if it's accepted I'll contribute a PR.

At runtime, one profile is selected through --profile / FNOX_PROFILE, and the effective config is resolved as:

top-level config + selected profile overrides

That works well for selecting one environment.

What I would like to support

The use case I am interested in is activating multiple profiles at the same time, as an ordered composition.
Conceptually, profiles would act like small partial implementations or mixins:

[profiles.aws.providers.aws]
type = "aws-sm"
region = "us-east-1"
[profiles.prod.secrets.DATABASE_URL]
provider = "aws"
value = "/prod/database-url"
[profiles.ci.secrets.CI_TOKEN]
provider = "aws"
value = "/ci/token"

Then a command could activate more than one profile:

fnox --profile aws --profile prod --profile ci exec -- ./app

or possibly:

FNOX_PROFILE=aws,prod,ci fnox exec -- ./app

The effective configuration would be:

top-level config
+ profiles.aws
+ profiles.prod
+ profiles.ci

with later profiles overriding earlier ones.
This would allow users to compose behavior by concern, for example:

• aws provides provider configuration
• prod provides production secret mappings
• ci adds CI-only secrets
• local overrides a few values for local development

Why this seems to fit the existing design

The current implementation already has most of the right pieces:

• ProfileConfig contains providers, default_provider, secrets, and leases.
• Config::get_providers(profile) and Config::get_secrets(profile) already build an effective view from top-level config plus one profile.
• Provider instances are named, so composing provider maps from multiple profiles seems like a natural extension.
• The main change would be moving from a single active profile string to an ordered list of active profile names.

[jdx]

yeah I think this makes sense