[Issue]: Inverting relationship for registering identifier prefixes

### Issue Title

Inverting relationship for registering identifier prefixes

### Issue Type

Process Improvement

### Problem Statement

Currently we have a situation when products want to use the prefix mechanism such as VRS and refget, where their specifications have said what those prefixes are and then use TASC to indicate that prefix is now reserved. In the last discussions within refget sequence collections, the group felt this relationship should be switched around with the idea that specs do not get to reserve the prefix in their spec, that it is done here and referred back to.

The improvement would be better oversight of what "things" are being assigned prefixes but also allows the specs to say "use what TASC says for this concept identity". It seemed this is a better way for it to work

### Scope Validation

Knowing what we can and should assign prefixes is difficult to understand. Especially as they only have meaning if they have become registered. Moving this into TASC means

- There is better oversight of what is given prefixes
- Why they've been given one
- It is at the right level of granularity
- Promotes better interoperability as the pathway for using these checksum identifiers with prefixes (though not exclusively for them) becomes clearer

### Proposed Solution(s)

We would recommend the current system is expanded in scope with additional oversight back into TASC. When a prefix recommendation is received it is presented to TASC and then approved. Not a lot is different to how we manage this now.

### Estimated Effort Level

Low (1-2 months, minimal resources)

### Success Criteria

To measure success I would expect

- Registration of prefixes remains easy to accomplish
- An increase in the number of prefixes (assuming products need them)

### How will this issue aid GA4GH harmonization?

The problem the prefixes is trying to solve is how can you tell what kind of typed identifier you are working with. Especially when the underlying character set and length of the identifier is the same. There is no way to know if one checksum derived ID is a VRS or a refget ID. Harmonisation at this level means a global GA4GH resolver, or similar bound resolver, knows what "thing" they have.

### Additional context

Please provide any additional pieces of information you feel is relevant to this issue

### Work Streams Raising This Issue

- [ ] Clinical & Phenotypic Data (Clin/Pheno)
- [ ] Cloud Work Stream
- [ ] Data Security
- [ ] Data Use & Researcher IDs (DURI)
- [ ] Discovery
- [ ] Genomic Knowledge Standards (GKS)
- [x] Large Scale Genomics (LSG)
- [ ] Regulatory & Ethics (REWS)
- [ ] Data Models & Schemas Committee (DaMaSC)
- [ ] Genomic Implementation Forum (GIF)
- [ ] Technical Team
- [ ] Other (specify below)

### Other Groups Raising This Issue

_No response_

### Work Streams That Will Be Impacted

- [ ] Clinical & Phenotypic Data (Clin/Pheno)
- [x] Cloud Work Stream
- [ ] Data Security
- [ ] Data Use & Researcher IDs (DURI)
- [x] Discovery
- [x] Genomic Knowledge Standards (GKS)
- [ ] Large Scale Genomics (LSG)
- [ ] Regulatory & Ethics (REWS)
- [ ] Data Models & Schemas Committee (DaMaSC)
- [ ] Genomic Implementation Forum (GIF)
- [ ] Technical Team
- [ ] Other (specify below)

### Other Groups That Will Be Impacted

_No response_

### Key Stakeholders to Consult

TASC but also VRS maintainers as the way this would work since they are the only other group that has used these prefixes. To note VRS was the first one to create the concept

### Products affected

Please list them here. It does not need to be exhaustive

### Additional Context

_No response_

### Priority Level

Low (can be addressed in normal course of work)

### Additional Tags

- [ ] Documentation
- [ ] API
- [ ] Schema
- [ ] Security
- [ ] Performance
- [x] Interoperability
- [ ] Compliance
- [ ] User Experience
- [ ] Infrastructure
- [ ] Testing

Start by reviewing the current TASC prefix-registration process and the VRS and refget specifications that use prefixes. Consult TASC and VRS maintainers to define the approval workflow and scope. Done means the revised registration approach is agreed and its requirements are documented clearly enough for affected specifications to refer back to TASC.

Written by the indexing model from the issue text.