ts_library produces source maps that link to bazels symlinked files not the real source

[Toxicable]

When using ts_library, it will produces source maps to bazels symlinked version of files that live in bazel-bin.
The source maps should point to your real source, not the ones in bazel-bin

When your target is the browser this isn't an issue since the browser can resolve the source maps and host it without a problems. This change will also have no affect here.
When your target is nodejs (nodejs_binary) this causes issues when trying to debug those files.

• Breakpoints inserted via IDE such as Visual Studio Code don't work.
  If you attach to a nodejs process via VSC you should be able to use it's breapoints feature just like you can in chrome, but if you place the breakpoint on the "real" file then it wont work since that's not the sourcemap's target. You must instead use debugger, then if you attach and hit the breakpoint VSC will open the sourcemapped file, once in the source mapped files you can then use breakpoints as expected

• tsserver does not handle working with the bazel-bin files.
  Once you start debugging the sourcemapped files tsserver (TS's language support server) TS support in VSC will start dropping out, eventually to the point where you get no support at all, autocomplete will be gone, error marking also, if you inspect your processes then tsserver will be running at 100% constantly in (I assume) an attampt to re-process all the files in bazel-bin aswell as you real source files, possibly without bounds (include/exclude).
  This issue here i've only noticed being distruptive lately at a codebase size of about 30K LOC, so if it were a big code base I don't see how this could scale.

[publicvirtualvoid]

This is one of the main issues I have with debugging at the moment

[alexeagle]

Yeah there are a cluster of issues around this right now. Since @mprobst is back and could probably help us understand the correct thing to do, I put this one on our bug bash sprint which starts Tuesday.

[mprobst]

@alexeagle sorry, I don't have any cycles for this.

I think you changed how source maps work before, maybe this is something for you to reason through and figure out what the right way to handle it is?

[alexeagle]

We have started fixing sourcemaps in other contexts, by post-processing the diagnostics after the tool produces them based on paths it observed during compilation. Probably the right thing to do here too

[alexeagle]

replaced by #321