Users may be running several slightly different versions of their service in production (e.g., due to staged rollouts).

Then when collecting profiles, those users may, intentionally or unintentionally, collect profiles from multiple different versions of the binary and merge them together for use as the PGO profile.

I believe we already handle these correctly, but it is not intuitive, so we should add tests to ensure this continues to work.

The interesting case are samples in functions that have moved (different StartLine) between profiles A and B:

1. Profiling merging uses (StartLine, Name, SystemName, Filename) as the Function identity key. Thus there will be 2 Functions with the same Name but different StartLine. Samples referencing these functions won't merge because they reference different Function ids.

2. When building the Node graph, we will end up with unique Nodes for each of the distinct Functions.

3. When processing Nodes to compute weights, we will calculate the same NodeMapKey for Nodes from each of the unique Functions (assuming line offsets within the function are unchanged). Thus, we will accumulate weights from the different Functions into the same NodeMap entry.

4. IRGraph construction then works as normal, finding merged weights from NodeMap entries.

This is quite fragile and we could easily break this without tests (or I missed something and it is already broken!)

cc @cherrymui @aclements