feat: fix pathways to allow debugging hot-transpiled modules

[connor4312]

Previously, this extension fared poorly if one attempted to debug a Node
script that had in-place transpilation going on (e.g. @babel/register or
ts-node). There were a few reasons for this.

The most trivial one is that we didn't do content hashing for Node
script as a performance optimization. Unfortuantely, we can't assume
that any file on disk is actually what we're running in this scenario :)

A second trivial one is that the source map filtering we added didn't
support source map data URIs. We added a filter to ignore source maps
coming from node_modules or outside the workspace folder, and we just
didn't have logic for matching data URIs there. Now, if we see a data
URI, we'll just treat the embedding file as the source map location for
comparison purposes.

The bulk of this commit deals with the third change. By default, we
eagerly throw out breakpoints that match lines the exact file path or
URI. This becomes problematic because the transpilation happens
in-place, generating compiled sources that live appear at the same paths
as the source files. The approach we take here is that if we see a
source map which lands breakpoints in a file for which we've previously
set breakpoints by URL, then remove the URL-set breakpoints in favor of
the sourcemapped breakpoints.

The bulk of changes were around resiliency for this, since breakpoints
become a little more dynamic now in some cases:

• We store a list of 'applying' breakpoints in addition to 'applied'
  ones, which we're able to remove or deadletter (e.g. if we run into a
  sourcemap while still setting a URL BP)
• We used to store only a single UI location for the breakpoint, we now
  keep track of them and will change the location if a breakpoint is
  moved or adjusted.
• Fixed a (probably rare) case where a BP could leak if a the thread
  changed while the breakpoint was being applied.

Fixes #127

[dgozman]

Hmm... The whole idea of transpiler transforming file in place sounds terrible. This means we loose the ability to debug either the original file, or the transformed one. Can we engage with @babel/register and/or other projects which do this kind of thing? IIUC, the easy fix for them would be to additionally include sourceUrl in the generated file which points to a different location, so that we don't even map generated file to non-matching source file. WDYT?

[connor4312]

I don't disagree, it is somewhat terrible, but it's been common practice in Node since the first transpilers were born...

I'll prototype and follow up with the maintainers of common tools in a few days, but this'll be a scenario we need to support for a good while regardless.

[connor4312]

Test flake seems unrelated