Allow specifying fixed values for attributes in refinements

Is your feature request related to a problem? Please describe.
I wish I could go about definining implementations of signals with the only difference being 1 or more attributes have fixed values.

Describe the solution you'd like

I want to be able to define my implementation/usage examples using yaml so that they can be generated at build time and kept up to date with base signal definition.

groups:
  - id: Implementation.db.mysql.client
    type: Implementation
    uses: package.db.sql.client
    scope:
      name: mysql.telemetry
      version: 5.0.0
    implements:
      - ref: span.xy.client
    attributes:
      - ref: db.system.name
        requiredValue: mysql
      - ref: db.collection.name
        brief: The MySQL table being used

Or in v2

implementation:
  - name: db.mysql.client
    uses: db.sql.client #package
    scope:
      name: mysql.telemetry
      version: 5.0.0
    implements:
      - ref: span.xy.client
    attributes:
      - ref: db.system.name
        requiredValue: mysql
      - ref: db.collection.name
        brief: The MySQL table being used

Or potentially even

scope:
  name: mysql.telemetry
  version: 5.0.0
  attributes:
    - ref: db.system.name
      value: mysql

implementation:
  - name: db.mysql.client
    uses: db.sql.client #package
    scope: mysql.telemetry
    implements:
      - ref: span.xy.client
    attributes:
      - ref: db.collection.name
        brief: The MySQL table being used

The min required field for an implementation would be id, type & extends.

Describe alternatives you've considered
Considered using duplicated info but ran into issue with requiring unique names etc see https://github.com/open-telemetry/semantic-conventions/issues/2389

Additional context
Helps adoption of open telemetry if people can easily find libraries that have implemented the signals desired and makes the barrier lower to documate other signals.

Connected to https://github.com/open-telemetry/semantic-conventions/issues/1484

The issue names no files, tests, or entry points; begin by locating Weaver’s YAML schema and build-time generation path. Compare the proposed refinement forms and define the accepted representation and validation behavior; done means fixed attribute values can be specified without duplicated definitions and generated examples remain current.