[chore] Automatically split attribute tables based on deprecation status

[thompson-tomo]

Changes

This splits the attribute tables based on the deprecation status.

This provides the following benefits:

• deprecated attributes no longer needs to be moved to seperate groups simplifying process and improving history
• The attributes on signals are grouped the same as the registry
• The deprecated tables can have a different structure with links to new attributes
• Reduction of items in table of contents.

Out of scope tasks:

• consolidating deprecated attributes in to main file
• Putting informative briefs back on attributes rather than duplicating deprecation reason.

Important

Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[lmolkova]

The previous PR (#2819) was closed - there is no support for this change among approvers and you've got feedback that this is a controversial change.

See #2623 and #2607 (comment) for the feedback points.

Lack of support from approvers along with the feedback usually means that there is no point in reopening the PR without some discussion. I'm going to close it.

[thompson-tomo]

@lmolkova i had gone and addressed the controversial points which entered around polluting signals pages with deprecated attributes. This pr makes no changes to which attributes are rendered hence I saw that as closed. It also doesn't introduce a new concept. After which I did raise it at a semconv meeting the other week and the feedback I got was to avoid needing to consolidate yaml files which was also implemented.

As it stands the changes introduced here are just:

• render deprecated attributes under the same heading as the non-deprecated siblings but in a different section. This is mostly used in the registry.
• use a reduced/tailored table for deprecated attributes to remove un-necessary content and be able to link to new attribute where appropriate.

[lmolkova]

thanks for the explanation. Not needing to separate deprecated from active will indeed be useful with schema v2 where we won't have groups anymore. Most of jinja work will need to be redone at that time anyway.

I don't believe changes in markdown are beneficial though. And I'd postpone jinja work until we have a need (schema v2).