Note [DCmmGroup vs CmmGroup or: Deterministic Info Tables]

Consulting Note [Object determinism] one will learn that in order to produce
deterministic objects just after cmm is produced we perform a renaming pass which
provides fresh uniques for all unique-able things in the input Cmm.

After this point, we use a deterministic unique supply (an incrementing counter)
so any resulting labels which make their way into object code have a deterministic name.

A key assumption to this process is that the input is deterministic modulo the uniques
and the order that bindings appear in the definitions is the same.

CmmGroup uses LabelMap in two places:

* In CmmProc for info tables
* In CmmGraph for the blocks of the graph

LabelMap is not a deterministic structure, so traversing a LabelMap can process
elements in different order (depending on the given uniques).

Therefore before we do the renaming we need to use a deterministic structure, one
which we can traverse in a guaranteed order. A list does the job perfectly.

Once the renaming happens it is converted back into a LabelMap, which is now deterministic
due to the uniques being generated and assigned in a deterministic manner.

We prefer using the renamed LabelMap rather than the list in the rest of the
code generation because it is much more efficient than lists for the needs of
the code generator.