Specify how delegated /routing/v1 API can support new protocols

Extracted loose ends from IPIP-337 (to unblock it), but we need to address below at some point.
cc @guseggert @aschmahmann @masih

## Open questions

- How do we deal with plain text labels from [table.csv](https://github.com/multiformats/multicodec/blob/master/table.csv) changing in the future?
- It happened before: [go-cid had invalid mapping](https://github.com/ipfs/go-cid/releases/tag/v0.2.0), and [we changed label for at least 4 codes](https://github.com/multiformats/multicodec/pull/283/files)
- Can we allow numeric values instead (indicate them in hex, start with `0x`)
- How do we allow for novel protocols that do not have multicodec registered?
- https://github.com/ipfs/specs/pull/337/files#r1044055388
- How does the use of Schema interact with systems like IPNI?
- https://github.com/ipfs/specs/pull/337/files#r1044060034

Maybe more tangible example:

- How does Iroh announce their blake3-specific data transfer protocol?

## Idea 1

> - `Protocol` is the multicodec name of the transfer protocol or an opaque string
> - for protocols with multicodec, a numeric code starting with `0x` can be used instead of name
> - for protocols without multicodec registered, we could go with UUID in hex form (also `0x` prefix, but we avoid collisions due to them bveing long enough)
>

## Idea 2

- state `Protocol` and `Schema` are opaque strings, and write convention how to return opaque records as base-encoded bytes.
- there is some conceptual ovelap with https://github.com/ipni/specs/pull/4