Add component version references and template formatting to extra-files configuration

[ryanfaircloth]

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

I'm working with a monorepo containing multiple containers and a Helm chart that depends on them. Currently, there's no way to:

Reference another component's version in extra-files updates (e.g., updating a Helm chart's values.yaml with container image tags)
Format versions using templates (e.g., v1.2.3 vs 1.2.3, or major.minor only)
Track dependencies between components without forcing all components to share the same version
The linked-versions plugin forces version synchronization across all components in a group, which is problematic when you want independent versioning. For example, if I have two containers (app1 at 1.2.3 and app2 at 2.5.1) and a Helm chart (at 3.0.0), I want:

Each container to version independently
The Helm chart to bump when either container changes
The Helm chart's values.yaml to reference the current container versions
The Helm chart to maintain its own version number (not adopt the container versions)
Describe the solution you'd like

Extend the extra-files configuration to support component references and template formatting:

New fields:

component: Reference another component's version instead of using the current component's version
template: Format the version using template variables ({{version}}, {{major}}, {{minor}}, {{patch}}, {{prerelease}}, {{component}})
bumpDependents: Whether changes to the referenced component should trigger a bump (default: true)
Behavior:

When app1 releases version 1.2.3, the Helm chart automatically bumps (e.g., to 3.1.0) and updates values.yaml with app1.tag: 1.2.3
When app2 releases version 2.5.1, the Helm chart bumps again (e.g., to 3.2.0) and updates values.yaml with app2.tag: v2.5.1
The Helm chart maintains its own independent version number
A synthetic commit (e.g., chore: update container dependencies) is added to the Helm chart when dependencies change
Describe alternatives you've considered

Using linked-versions plugin: This forces all components to share the same version, which doesn't work when containers should version independently. If app1 goes from 1.0.0→1.1.0, I don't want app2 to jump from 2.0.0→1.1.0.

Custom plugin: I could write a custom plugin to handle this, but it seems like a common use case that would benefit from built-in support. Many projects have similar dependency patterns (containers→Helm, libraries→applications, packages→examples).

Manual updates: Manually updating values.yaml defeats the purpose of automated release management and is error-prone.

Post-release scripts: Running scripts after releases to update dependencies adds complexity and delays, and doesn't integrate with release-please's PR workflow.

Additional context

This feature would be useful for various dependency scenarios:

Helm charts depending on container versions
Application packages depending on library versions
Examples/documentation depending on package versions
Docker Compose files referencing image tags
Terraform modules referencing container images
The solution maintains backward compatibility (all new fields are optional) and complements the existing linked-versions plugin for different use cases:

Use linked-versions when you want synchronized versions (e.g., coordinated library releases)
Use extra-files with component references when you want independent versions with dependency tracking
Example workflow:

Developer merges PR that changes app1
Release-please creates release PR for app1 (1.2.2→1.2.3)
Release-please detects my-chart has extra-files referencing app1
Release-please creates/updates release PR for my-chart (3.0.5→3.0.6) that updates values.yaml with the new app1 version
Both releases happen independently with proper version tracking