Support release notes for packages published via package feeds

# Description

FHIR packages can be registered in the official FHIR package registry through external package feeds listed in the `FHIR/ig-registry`.

While package feeds allow package versions and their basic metadata to be discovered and imported, there does not appear to be a standardized way to provide **release notes for a specific package version** through such a feed.

This creates a difference between packages that are published directly through registry tooling that supports release notes and packages that are discovered through external package feeds.

For example, a terminology publisher may provide:

* a package name and version
* a package description
* a publication date
* the downloadable `package.tgz`
* detailed version-specific release notes

The release notes may describe changes such as:

* added or removed terminology concepts
* changes to existing concepts
* metadata changes
* bug fixes
* dependency changes
* other relevant changes between package versions

Currently, these version-specific release notes cannot apparently be propagated through the package feed into the official FHIR package registry.

# Example use case

The German Federal Institute for Drugs and Medical Devices (BfArM) publishes FHIR terminology packages via an external package feed, for example:

`https://terminologien.bfarm.de/feeds?publishToHl7=true`

For each package version, additional structured release information may be available on the publisher side.

It would be useful if this information could also be exposed as the **Release Notes** of the respective package version in the official FHIR package registry.

For example:

```text
de.gematik.hddt.terminology#1.0.0

Release notes:
Initiale Version des FHIR Packages für HDDT terminologies 1.0.0. Dieses Package enthält die Terminologien für die Spezifikation Health Device Data Transfer (HDDT) im FHIR-Format. Es stellt die erforderlichen ValueSets, CodeSystems und ConceptMaps bereit, um den standardisierten und interoperablen Austausch von geräte-generierten Gesundheitsdaten zwischen Hilfsmitteln, Implantaten und Digitalen Gesundheitsanwendungen (DiGA) gemäß § 374a SGB V zu unterstützen. Das Package basiert auf international etablierten Terminologien wie LOINC und SNOMED CT. Deren semantische Eigenschaften werden auf FHIR-Terminologie-Ressourcen abgebildet und für die maschinenlesbare Verarbeitung innerhalb von HDDT-basierten Implementierungen verfügbar gemacht. Ein zentrales Element dieses Packages sind die durch HDDT definierten Mandatory Interoperable Values (MIVs). MIVs repräsentieren semantisch klar abgegrenzte Klassen von Messwerten, die zur Unterstützung spezifischer DiGA-Anwendungsfälle und therapeutischer Zielsetzungen erforderlich sind. Jeder MIV wird durch beschreibende Semantik sowie ein kuratiertes Set von Terminologie-Codes definiert, um Interoperabilität und klinische Eignung der ausgetauschten Messdaten sicherzustellen. Darüber hinaus dienen MIVs als semantische Grundlage für SMART-on-FHIR v2 Scopes der Autorisierung, wodurch eine feingranulare, messwertspezifische Zugriffskontrolle innerhalb von HDDT-basierten Backend-APIs ermöglicht wird. Dieses FHIR-Package bildet die semantische Interoperabilitätsschicht für HDDT-Profile und Backend-Dienste und ist für den Einsatz in FHIR R4-basierten Implementierungen vorgesehen, um die Integration persönlicher Gesundheitsgerätedaten in DiGA-gestützte Versorgungsprozesse zu ermöglichen.
```

# Question / Proposal

Is there already a supported mechanism for providing version-specific release notes through an external FHIR package feed?

If not, would it make sense to extend the package feed format with an optional release-notes element, for example conceptually:

```xml

...

```

The exact representation is not important from our perspective. The main requirement would be to have a standardized mechanism that allows external package publishers to provide **version-specific release notes** which can then be displayed by the official FHIR package registry.

# Expected benefit

This would improve:

* transparency of package updates
* traceability between package versions
* interoperability between external package publishers and the official registry
* visibility of terminology and conformance resource changes
* consistency between directly published packages and packages imported through external feeds

Would this be something that should be defined in `FHIR/ig-registry`, the FHIR package feed specification, or another repository/specification?

Read the referenced FHIR/ig-registry and external package feed specification first, then trace how feed metadata is imported and displayed in the official registry. Done means determining whether version-specific release notes are already supported or defining where an optional standardized release-notes element should be specified and exposed.

Written by the indexing model from the issue text.