Which issue(s) does this change fix?

This PR adds two enhancements to the parameter override file functionality introduced in #7876:

1. Relative path resolution for nested includes - Parameter files can now reference other files using paths relative to their own location, rather than requiring paths relative to the project root
2. $include key support - Dict-based parameter files (YAML/TOML) can now include other files using a special $include key, providing the same composition capabilities that list-based files already had

Why is this change necessary?

1. Improved ergonomics for nested includes: When organizing config files in subdirectories (e.g., ./config/a.yaml and ./config/b.yaml), it's unintuitive for a.yaml to reference b.yaml as file://config/b.yaml instead of simply file://b.yaml. Relative path resolution makes file organization more natural and maintainable.
2. TOML parity with YAML: The previous implementation only supported file includes via list syntax, which worked for YAML but did not allow TOML dict-based files to include other files.

How does it address the issue?

1. Relative path resolution: Added a current_file parameter to track the file being processed. When a file:// reference is encountered, relative paths are resolved against current_file.parent instead of the project root.
2. $include key: Added support for a special $include key in dict-based parameter files that accepts either a single file path or a list of file paths. I picked this key name because it is not a valid cloudformation parameter so it should be fully backwards compatible. Another option was __include which didn't need to be quote-escaped in TOML but overall didn't look as pretty.

What side effects does this change have?

This changes how file:// references work for parameter overrides in a way that is not backwards compatible. However, impact is limited since:

• The feature was introduced very recently (Expand parameter overrides #7876)
• It has not yet been documented in official AWS documentation
• The new behavior is more intuitive and aligns with user expectations

Mandatory Checklist

PRs will only be reviewed after checklist is complete

• Review the generative AI contribution guidelines
• Add input/output type hints to new functions/methods
• Write design document if needed (Do I need to write a design document?)
• Write/update unit tests
• Write/update integration tests
• Write/update functional tests if needed
• make pr passes
• make update-reproducible-reqs if dependencies were changed
• Write documentation

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Documentation

Old and busted

When using file:// to include external parameter overrides, there were limitations to include further levels of nested files. YAML had to be a list:

- StringParam: Pam Param
- NumberParam: 42
- file://other_yaml_params.yaml
- file://toml_params_because_I_can.toml

TOML just didn't support it:

StringParam = "Pam Param"
NumberParam = 42
file://another_toml_file.toml # This will fail because it is not valid TOML

New hotness

The root object can now be a dict if you want using $include:

# YAML
$include: file://base.yaml
Environment: prod-b

And TOML can now join the party too:

# TOML
'$include' = 'file://default.toml'
Environment = 'prod-b'

It's worth nothing that $include is a generic parameter inclusion that supports ALL parameter formats. It is not specifically limited to file:// references. For example, the following snippets are also valid:

# YAML
$include: foo=bar

# YAML
$include:
  - file://default.yaml
  - file://prod.yaml
  - foo: bar
  - x=y
Environment: prod-b

# TOML
"$include" = [
  "file://default.yaml",
  "file://prod.yaml",
  { foo = "bar" },
  "x=y"
]
Environment = 'prod-b'