[tailscale] runtime, runtime/metrics: add goroutine stack size histogram

[bradfitz]

TailscaleReadStackStats tells a goroutine about its own stack, but
finding out how the stacks of all the goroutines in a server are
spread across size classes still meant walking every goroutine, and
nothing reports how often stacks are being copied. The runtime itself
only exposes aggregate stack bytes, in runtime/metrics and MemStats.
For a server holding millions of idle connections, a walk on every
metrics scrape is exactly the O(goroutines) cost we want to avoid.

Add four metrics to runtime/metrics, all maintained incrementally so
that reading them never touches the goroutines.

/tailscale/sched/goroutines-by-stack-size:bytes is a histogram whose
buckets are the power-of-two stack size classes, each counting the
live goroutines currently in that class. It includes runtime system
goroutines, so at rest the buckets sum to /sched/goroutines:goroutines.

/tailscale/sched/stacks/growths:events and
/tailscale/sched/stacks/shrinks:events count stack copies since
program start in each direction, and
/tailscale/sched/stacks/copied:bytes counts the bytes of in-use stack
those copies moved. Their rates show whether stacks are thrashing,
growing on each request and being shrunk back by the GC while idle,
and what that costs.

The histogram is dead-reckoned the way the GC pacer tracks its
scannable stack total, at the same three sites (newproc1, gdestroy,
and copystack), plus oneNewExtraM so that a cgo callback goroutine
growing its stack does not push a bucket negative. Each P keeps an
int32 counter per size class, so goroutine creation and exit touch no
shared atomics; a goroutine created on one P and exiting on another
leaves offsetting entries whose sum is still correct. The counters are
int32 rather than int64 so that other Ps can read them atomically on
32-bit platforms without the alignment requirements that
TestAtomicAlignment enforces, and, like the pacer's maxStackScanDelta,
they are flushed to a global atomic once they drift a small slack from
zero so they cannot overflow. Destroying a P flushes its counters too,
like goroutinesCreated. The three cumulative counters are plain global
atomics, since a stack copy is rare and expensive next to an atomic
add.

Reading the histogram sums the global and per-P arrays under
sched.lock, so it costs O(GOMAXPROCS): about 240ns whether there are
zero or ten thousand goroutines.

The test compares the incrementally maintained histogram against a
stop-the-world walk of every goroutine, which must match exactly,
after creating goroutines, growing stacks, shrinking them via GC,
changing GOMAXPROCS in both directions, and letting the goroutines
exit. It also checks that the cumulative counters advance by at least
what one goroutine's TailscaleReadStackStats reports for itself. A
manual cgo check confirmed that a callback on a C-created thread that
grows its stack to 512 KiB is accounted for as well.

Updates #184
Updates https://github.com/tailscale/corp/issues/48120
Updates golang#81527