Feat: Some type of way to merge key prop and useOpaqueIdentifier result

[SoAsEr]

Currently, the expected way to handle an unknown at compile time number of labels is to put them each in their own component. However, when creating tables, this causes a mess of callbacks, as the only way to do it (that I can think of anyway) is to pass a callback into the table header components, have them create their own unique identifier, and then use a useEffect to give the parent those identifiers, have the parent pass those identifiers to the rows, and then have each row generate its opaque own unique identifiers and pass both to the cells. Note that this doesn't work currently because of these two bugs:
#18594
#20127

However, react already has a way to differentiate items in loops: the key prop. To me, it would make sense to provide a function which merges a key prop with a unique identifier. This would allow the parent to generate the unique identifiers and pass them to the children, rather than having callbacks which cause a rerender. It would even make #20127 less relevant because there would be fewer motivating reasons to do so.

mergeOpaqueIdentifierAndKey is very wordy, but describes exactly what's going on. I don't have any particular preference about the name.

[eps1lon]

Prior art reactjs/rfcs#32 (comment).

Naively we could just append the key to the generated id. But this would increase the number of bytes sent when doing SSR and also put new constraints on what kind of strings we can pass to key

[SoAsEr]

The other option would be to sort the keys added once we start the toString and then append their index. We wouldn't even have to use string compare at first. We could sort by length (which is faster) and then fall back to string comparison if their lengths are equal.

[SoAsEr]

New approach is totally different and doesn't need this complicated scheme: reactwg/react-18#111