Generate identifiers for the expanded instances

## Background
Currently, a domain model specifies the common object that could have multiple occurrences:
```gql
type Seat {
instanceTag: InCabinArea2x2
}
```
Where the `InCabinArea2x2` corresponds to the expanded labels:
- `ROW1.DRIVERSIDE`
- `ROW1.PASSENGERSIDE `
- `ROW2.DRIVERSIDE`
- `ROW2.PASSENGERSIDE`
Those instance tags can be arbitrarily defined by the user.

## Open questions
Currently, the tools creates unique IDs for the elements like:
- Concept IDs
- `ns:Seat` (based on naming only)
- Realization IDS
- `0xA2C48D71` (based on the metadata)

### Do we need to create explicit IDs for each of the possible instances of that concept?
For example:
- `myPrefix:Seat.ROW1.DRIVERSIDE`
- `myPrefix:Seat.ROW1.PASSENGERSIDE `
- `myPrefix:Seat.ROW2.DRIVERSIDE`
- `myPrefix:Seat.ROW2.PASSENGERSIDE`

### If so, what is the best approach to do it?
Considering that any breaking change will incur in a new realization ID.
And that realization ID itself uses the specified instances as an element for the hash ID.

## Possible solution
Currently, the CLI tools include the specification registry function that persists the evolution of the identifiers as the domain model (hosted in git) changes over time. Such registry is persisted as a JSON-LD file as:

```json
{
"@context": {... },
"@graph": [
{
"@id": "ns:Seat", # <--- Concept ID
"@type": "Object",
"specHistory": [ # <--- Realization IDs as a list
{
"id": "0x9B020962", # <--- Realization ID in V.0.1
"timestamp": "2025-05-14T10:22:00.000000"
},
{
"id": "0xA2C48D71", # <--- Realization ID in V.0.2 (Latest, and currently valid realisation of the concept "Ns:Seat")
"timestamp": "2025-05-14T10:22:30.000000"
}
]
},
...
]
}
```

It is possible to extend that file to persist the instances liked to the corresponding realization ID and the concept ID.

```json
{
"@context": {... },
"@graph": [
{
"@id": "ns:Seat", # <--- Concept ID
"@type": "Object",
"specHistory": [ # <--- Realization IDs as a list
{
"id": "0x9B020962", # <--- Realization ID in V.0.1
"timestamp": "2025-05-14T10:22:00.000000"
"instances": ["ROW1.DRIVERSIDE", "ROW1.PASSENGERSIDE", "ROW2.DRIVERSIDE`", "ROW2.PASSENGERSIDE"]
},
{
"id": "0xA2C48D71", # <--- Realization ID in V.0.2 (Latest, and currently valid realisation of the concept "Ns:Seat")
"timestamp": "2025-05-14T10:22:30.000000"
"instances": ["FRONT.DRIVERSIDE", "FRONT.PASSENGERSIDE", "FRONT.DRIVERSIDE`", "FRONT.PASSENGERSIDE"] # <--- new set of instance tags
}
]
},
...
]
}
```
In this example, let's assume that the breaking change was to change the instance tags themselves (e.g., from `ROW1` to `FRONT`).
The registry records that explicitly.