Reimplement input sourcemap merging using range matching instead of closest-position matching

[loganfsmyth]

Q	A
Fixed Issues?	Fixes #7632
Patch: Bug Fix?	Y
Major: Breaking Change?	Not unless things were relying on our previous awful maps
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR
Any Dependency Changes?
License	MIT

This PR ended up bigger than I'd originally expected, so sorry about that. The core of it comes down to the fact that just calling generatedPositionFor is an extremely bad/inaccurate way to merge two sourcemaps.

The core of this PR is making full use of the fact that source mappings are generally processed as ranges rather than individual locations. The new code walks from the original input mappings down to the actual mappings generated by Babel, but does so taking ranges into account. Rather than blindly calling generatedPositionFor, we explicitly search for the set of ranges that overlap.

This fix is driven by my work on FF in firefox-devtools/debugger#5561

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/7736/

[gzzhanghao]

Can we use original.column + item.original.column - generated.column here? We'll have higher precision sourcemap if so.

[loganfsmyth]

I don't follow that logic. If the input sourcemap had a range over a set of locations, isn't it reasonable to expect exactly the same range over the original files in the output map?

[gzzhanghao]

I'm not sure about that, in vue-loader's case column info are missing with original.column.

original.column + item.original.column - generated.column is based on an assumption that the mapped range will be exactly same as the original one. There may be exceptions, so I'm not sure if that will lead to any problems.

[loganfsmyth]

is based on an assumption that the mapped range will be exactly same as the original one.

That is my primary concern. I don't think that's a safe assumption to make for merge logic that should ideally be fairly generic. Any kind of math trying to calculate column numbers would be making assumptions about the structure of the code being mapped. I don't think I'm personally comfortable with doing that.

[loganfsmyth]

Fixed a few small issues with this. I'm probably going to merge it after the tests pass, since it seems like realistically no-one has the background to review it...