Add support for global env file to be applied to all stacks.

[mstrhakr]

Summary

Add support for global env file to be applied to all stacks.

Detailed description

Add support for global env file to be applied to all stacks. Using multiple env files is supported by compose, we would just need to check it its set and add --env-file [global env file] to the appropriate calls. Suggested originally here https://forums.unraid.net/topic/197334-plugin-compose-manager-plus/page/5/#findComment-1618341

We would need to ensure load order is correct as from what I've read the env files can override eachother, first --env-file is lowest priority and last is highest priority.

Alternatives considered

Copy paste reusable env vars into each projects env file.

[lordraiden]

Please consider the option to be able to choose a custom path and custom file name just for flexibility.

I would frame this as a per-stack environment resolution layer, not a single implicit global .env. Docker Compose already supports multiple --env-file flags, reads them in order, and lets later files override earlier ones; if --env-file is omitted, Compose falls back to .env / COMPOSE_ENV_FILES.

1. Per-stack opt-in Each stack should explicitly choose whether to inherit a shared env set. No implicit global injection into every project.

2. Support multiple env files The plugin should allow an ordered list of env files, e.g. base.env -> common.env -> stack.env, because Docker Compose already supports multiple --env-file entries and applies them in order.

3. Deterministic precedence The UI should show the exact resolution order and the winning value for duplicates, so overrides are predictable and debuggable.

4. Pre-flight validation Before up, validate that every configured env file exists and is readable. Compose errors on invalid env-file paths, so this should be caught early in the plugin UI.

5. Resolved environment preview Add a preview/dry-run view that shows the final interpolated values after merging all env files, so collisions and unintended overrides are visible before deployment. Compose uses env files for interpolation, so this preview should reflect the same resolution logic.

6. Runtime injection only The plugin should pass env files at compose invocation time instead of rewriting stack files. That keeps the compose project immutable and makes the behavior easier to audit.

7. Preserve stack isolation Shared env files should not be broadcast to all stacks by default. Scope them per project, so unrelated compose apps do not inherit variables they do not need.

This gives you flexibility without turning the plugin into a hidden global configuration system.

[mstrhakr]

Custom path and filename makes sense. Per stack option to ignore global env seems like a smart idea also. In my head there would be a global env settable in the plugin settings, plus a stack level env, but how/where do you see a third layer fitting in, unless you would just want an 'Add Env' button in the stack settings that allows for adding multiple and adjusting load order. That would probably work. Then a resolved env vars section in the settings to show the full list of resolved variables based on load order and such.