FSP version strings are hard to extract and not tied to specific binaries

The current FSP versioning scheme makes it difficult to identify which binary
corresponds to which version. Recent commit messages show several different
possible version formats:

- `Edge Platforms PTL-H PV (3515_56) FSP`
9746b8c492d9c06882ee55ae29d86d8f65205f2d
- `ASL IPU26.2 v6491_51` 3aebe88923ecbb639ad95abaebe29cb190ddec57
- `Alder Lake FSP C.1.75.10` 95f32b770cddc3df401a29828a479bd74370de38
- `BirchStream FSP (0041D92)` 9623d524500c140a6b11d2c727cb282b54962f09

Different platforms use different styles. The version sits inside free-form
prose, and there is no git tag or other reference that authoritatively links a
version string to a specific binary.

Several norms and recommendations expect the integrators to provide a clean,
machine-readable version field for each firmware component to be distributed
alongside the firmware, including:
- [EU Cyber Resilience Act, Annex I, Part II, point (1)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)
> Manufacturers of products with digital elements shall:
> (1) identify and document vulnerabilities and components contained
> in products with digital elements, including by drawing up
> a software bill of materials in a commonly used and machine-readable
> format covering at the very least the top-level dependencies
> of the products;
- [BSI TR-03183-2](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2_v2_1_0.pdf?__blob=publicationFile&v=5)
> 3.1 Definition of SBOM
> A “Software Bill of Materials” (SBOM) is a machine-processable file containing supply chain relationships
> and details of the components used in a software product. It supports automated processing of information
> on these components.
> (...)
> 5.2.2 Required data fields for each component
> (...)
> Component Version:
> (...)
> 2. Identifiers according to Semantic Versioning or alternatively
> Calendar Versioning SHOULD be used if one determines the
> versioning scheme; this is often the component creator.
- [CISA: 2025 Minimum Elements for a Software Bill of Materials (SBOM](https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf)
- [NIST SP 800-53 control SA-10(5)](https://nist-sp-800-53-r5.bsafes.com/docs/3-17-system-and-service-acquisition/sa-10-developer-configuration-management/)

A consistent scheme would help integrators to meet these expectations without
writing platform-specific version extraction logic and keep a high quality of
their SBOMs.

Taging each release commit in git in a way so the version string maps to a
specific tree and the binaries it contains, and introducing a common versioning
scheme would be perfect. If not feasible there still exist ways in which the
versioning could be improved:
- Adopt a single version format across platforms (SemVer/CalVer?)
- Include the version string in the binary names in a structured way
- Add a structured field in commit message, or a small machine-readable metadata
file next to the binary

Improving the FSP versioning flow would allow firmware integrators for a better
compliance with the security regulations and make the SBOMs more clean,
reliable, and attestable. Using a common and well-known versioning scheme across
the FSP releases would allow the parties interested in the SBOM to better
understand whether a given firmware contains the newest version and whether it
contains known vulnerabilities.