Proposal: Extend CycloneDX model to support hardware-software interface semantics

## Summary

Current CycloneDX specifications provide strong support for representing software components, dependencies, and vulnerability metadata. However, for cyber-physical systems (embedded, automotive, aerospace, industrial IoT), there is a missing semantic layer: explicit representation of hardware-software interface contracts.

This includes interactions such as:
- Memory-Mapped I/O (MMIO)
- Hardware register mappings
- Interrupt interfaces
- DMA channels
- Firmware-to-RTL lineage (e.g., High-Level Synthesis flows)

We refer to this missing abstraction as an **Interface Bill of Materials (IBOM)** concept.

##Problem Statement

SBOM and HBOM artifacts exist independently, but CycloneDX currently lacks a structured way to represent:

- relationships between firmware binaries and hardware registers
- interface-level dependencies between software drivers and RTL modules
- lifecycle changes in hardware-software contracts across updates
- temporal validity of hardware-software interfaces (e.g., FPGA reconfiguration)

As a result, interface-level risks such as firmware-to-gate contract drift cannot be represented or analyzed using existing BOM structures.

## Proposed Direction (Non-normative)

Rather than introducing a new BOM type, this proposal suggests exploring whether CycloneDX extension mechanisms can represent interface semantics using:

- component `properties`
- `externalReferences`
- relationship metadata
- graph-like dependency extensions

## Example (Illustrative Only)

```json
{
"type": "firmware-interface",
"name": "UART_MMIO_Interface",
"properties": [
{
"name": "mmio.baseAddress",
"value": "0x40001000"
},
{
"name": "register",
"value": "UART_STATUS:0x04:read-only"
}
],
"relatedComponents": [
"uart_driver.c",
"uart_controller.v"
]
}

Start by reviewing CycloneDX's component properties, externalReferences, relationship metadata, and graph-like dependency extensions against the proposed MMIO, register, interrupt, DMA, and firmware-to-RTL examples. Done would require an agreed, implementable extension design for representing hardware-software interface semantics, but this issue does not define a specific file, test, or acceptance criteria.

Written by the indexing model from the issue text.