Add package-specific FMF metadata to Reproducer Agent

[Koncpa]

Add package-specific FMF metadata to the Reproducer Agent

TODO:

• Add unit tests for YAML parsing, prompt rendering, and queue propagation.
• Update docstrings where appropriate.
• Update Reproducer documentation and the agents-as-skills mirror.

What this does:

Adds support for selected package-specific FMF metadata from the package rules
repository's ymir.yaml:

• require
• recommend
• environment
• duration
• tier
• tag

The workflow now:

• Reads and validates reproducer.fmf configuration.
• Passes the configuration from the reproducer queue to the agent.
• Instructs the agent to merge the values into generated or adapted main.fmf.
• Keeps the existing default behavior when no package customization exists.
• Rejects unsupported FMF configuration keys instead of silently ignoring them.
• Keeps the Reproducer Agent skill and documentation synchronized.

Fixes https://redhat.atlassian.net/browse/PACKIT-5438

[TomasKorbar]

Let's do a thought experiment and take this up a notch. This feature is result of discussion with ruby maintainer where they tag the test according to what Ruby version it is supposed to test. With this they would be forced to do rules for each version of ruby, which would be copy paste mostly and then one changed tag and that defeats the purpose of shared rules we've been requested to support. We need to support some templating and its worth thinking through whether this should be in a separate file. Lets discuss this further on today's meeting.

[Koncpa]

@TomasKorbar So as we agreed we keeping the mapping inside ymir.yaml I tried to another layer for templating based on RHEL stream version WDYT?

reproducer:
  enabled: true
  context:
    by_fix_version:
      rhel-10.3:
        runtime_version: "3.3"
      rhel-9.9:
        runtime_version: "3.1"
  fmf:
    tag:
      - "ruby-${runtime_version}"
    environment:
      RUBY_VERSION: "${runtime_version}"

Also could you confirm:

1. Is fix_version the correct selector, or should this use target branch,
   module stream, or another context value?
2. Is ${variable} an acceptable interpolation syntax?
3. Which built-in context variables should Ymir expose?
4. What should happen when a mapping or variable is missing?