[robhogan]

Undoes a behaviour change from #1981 that, while not a technical regression, in practice reduced effectiveness of symbolication.

hermesc emits several mappings at some bytecode offsets, eg at a function's entry: its declaration, then its first instruction. #1981 made composeSourceMaps keep all of them, but:

• Only the last covers any code, since a mapping's segment runs to the next one. The others can't be the answer to a lookup by position.
• Consumers that take the first mapping at a column, including metro-symbolicate and trace-mapping, now resolve these offsets to the wrong place, or to nothing.

For example, a frame in return {run: cb => cb()}; in RN's console.js polyfill:

$ metro-symbolicate composed.map < trace.txt
    at anonymous (address at …/js-polyfills/console.js:576:run)  # 0.87.1
    at anonymous (address at null:null:null)                     # main

On an RN 0.88 Android release build, 2,060 of 137,616 lookups at function entries change, 426 of them to null.

This keeps only the last mapping at each position, as Metro's Consumer resolves it, and keeps #1981's speedup. #1981 is unreleased, so its changelog line should come out of the 0.87.2 notes.

Changelog: Internal

Test plan:

• The test from composeSourceMaps: Keep mappings that share a generated column #1981 now expects only the last mapping.
• Composing RN 0.88 release maps with their hermesc -O maps (Android, minified iOS) gives output byte-identical to 0.87.1.
• Timing against main is within noise.