Spans capture the ID of the goroutine that created them, and expose it
in instrumentation. This patch makes the goroutine ID mutable, and
teaches the Stopper to update it for async tasks. This way, the spans
for the async tasks will have the correct goroutine ID - the task's
goroutine.

Release note: None

/debug/tracez lets users take a snapshot of the active spans registry
and render the new snapshot, or one of the previously taken snapshots.
The Tracer can hold up to 10 snapshots in memory.

The PR description has a screenshot.

When visualizing a snapshot, the page lets you do a number of things:
1. List all the spans.
2. See the (current) stack trace for each span's goroutine (if the
   goroutine was still running at the time when the snapshot was
   captured). Stack traces can be toggled visible/hidden.
3. Sort the spans by name or start time.
4. Filter the span according to text search. The search works across
   the name and stack trace.
5. See the full trace that a particular span is part of.

For the table Javascript providing sorting and filtering, this patch
embeds the library from https://listjs.com/ .

Limitations:
- for now, only the registry of the local node is snapshotted. In the
  fuiture I'll collect info from all nodes.
- for now, the relationships between different spans are not represented
  in any way. I'll work on the ability to go from a span to the whole
  trace that the span is part of.
- for now, tags and structured and unstructured log messages that a span
  might have are not displayed in any way.

At the moment, span creation is not enabled in production by default
(i.e. the Tracer is put in TracingModeOnDemand by default, instead of
the required TracingModeActiveSpansRegistry). This patch does not change
that, so in order to benefit from /debug/tracez in all its glory, one
has to run with COCKROACH_REAL_SPANS=1 for now. Not for long, though.

Release note: None

Currently, to manage proper JS dependency resolution with bazel,
we need to do one more extra step (which isn't automated yet):
explicitly specify the list of dependencies required by Db Console
in its BUILD.bazel file.

Another issue that is solved with this change is path resolution for
"node_modules" in Webpack config file. Path resolution for NPM modules
in webpack relies on project structure and it doesn't work well with
the way bazel places outputs.

Release note: None