Allow explicit provisioner selection for `environment` resources

[Siddhartha-singh01]

Is your feature request related to a problem? Please describe.

The built-in environment provisioner (envprov) is hardcoded into the generate command and always resolves variables via os.LookupEnv. In internal/command/generate.go:

environmentProvisioner := new(envprov.Provisioner)
loadedProvisioners = append(loadedProvisioners, environmentProvisioner)

There's no way for a developer to say "use a .env file for local dev" or "use AWS SSM in production." Which provisioner handles environment resources is silently determined by ordering in the list (slices.IndexFunc returns the first match), making it hard to debug or override.

Describe the solution you'd like

Promote envprov to a first-class, loadable provisioner type the same way templateprov and cmdprov already work. The provisioner loader in internal/provisioners/loader/load.go currently handles template:// and cmd:// URI schemes. Adding a local-env:// scheme would let the loader parse and load environment provisioners from the existing .provisioners.yaml files.

For example, a developer could define this in their provisioners file:

- uri: local-env://default-provisioners/environment
  type: environment
  description: Pulls values out of the local environment as outputs to an environment resource


The built-in `os.LookupEnv` behavior should stay as the default when nothing is configured, so existing Score files keep working as-is.

**Describe alternatives you've considered**

1. **Writing a community provisioner for each source** Works today (e.g. the `dotenv` provisioner), but the selection between built-in and community is still implicit and order-dependent.

2. **Removing the built-in provisioner entirely**  Would break backward compatibility for users relying on the current `os.LookupEnv` default.

3. **Keeping things as they are**  Functional, but the "magic" resolution gets harder to reason about as more community provisioners are added.

**Additional context**

Came out of the discussion in #483  @chris-stephenson pointed out that while the `environment` resource type is "special," the provisioner backing it shouldn't be magic and should be overridable. The current [`envprov.Provisioner`](https://github.com/score-spec/score-compose/blob/main/internal/provisioners/envprov/envprov.go) matches any resource with `type == "environment"` and `class == "default"`, and defaults its `LookupFunc` to `os.LookupEnv`  none of which the developer can change.

[chris-stephenson]

Thanks for filing the issue. A few points on the approach:

I would not introduce new config strcutures (e.g. in .score-compose/config.yaml)
Also: Score files should be environment and platform agnostic This means that it is not appropriate to specify the dotenv provider in teh Score file itself. The environment resource type should be resolved in a platform and environmengt agnostic way.

I think the easiest way of including this is into the provider system is to promote the envprov provisioner to a top level provisioner type alongside templateprov and cmdprov. In that way, developers can just use their existing provisioners file.

For example:

- uri: local-env://default-provisioners/enbvironment
  type: environment
  description: Pulls values out of the local environent as outputs to an environment resource

To mimic the current behaviour, an entry for the envprov provisioned could be attached to environments in internal/command/default.provisioners.yaml

Care needs to be taken with:

• Validation of the provider (e.g. handling of expected_outputs)
• Provising a fall back for older implementations that assume the envprov provider is used (Although given [bug] Infinite recursion in Provisioner.Class(), Type(), and Description() methods #481 it might be possible to ignore this actually)

[Siddhartha-singh01]

Thanks for the direction @chris-stephenson that's a much better approach than what I proposed.

So the idea is to treat envprov as a first-class provisioner type that the loader recognizes (like it already does for template:// and cmd://), rather than having it hardcoded in generate.go. That way developers just drop an entry in their .provisioners.yaml and they're done no new config files, no changes to Score files.

Looking at the loader, I think the main work would be:

1. Adding a local-env (or similar) case to the URI scheme switch in loader/load.go
2. Giving envprov a Parse() function so it can be loaded from YAML like templateprov and cmdprov
3. Adding a default entry in internal/command/default.provisioners.yaml so the current behavior is preserved out of the box

I'll also look into the expected_outputs validation and the backward compat question you raised sounds like #481 might simplify that.

I'll update the issue description to match this direction. Happy to start on a draft PR once we're good on the approach!

[chris-stephenson]

Thanks @Siddhartha-singh01 , sounds like a good starting point.