Before this patch, the registry only contained (local) roots. A child
span was not part of the registry directly; it was part of it indirectly
if the parent was recording at the moment when the child was opened.

I believe the fact that a child of a non-recording span is not part of
the registry is not principled, just path dependency. This patch makes
child spans indirectly part of the registry even if the parent is not
recording at the moment when the child is created, by having children
always register themselves with the parent, even if the parent is not
recording.

I got rid of the maxChildrenPerSpan limit on the number of open children
that a span keep track off. This limit was fairly non-sensical (it
probably started as more sane but then was refactored into non-sense) as
it applies to open spans but not to recordings of the finished children.
The point of this limit originally was to bound the memory use of
recordings. By acting only on open children, it had no such effect.
Indeed, there's pretty much no reason to bound the number of open
children tracked by a parent, and so this patch removes the limit. In
the next commit we'll get a new limit that refers to sizes of
recordings.

---

This patch also improves the scalability of creating child spans by
avoiding to attempt to remove them from the registry on Finish(). This
attempt was useless because we knew that the child span was not part of
the registry. It was also expensive, since it meant locking (and thus
synchronizing on) the registry. Thus, we now only attempt to remove
roots from the registry.

The scalability increase can be seen in the following:

GOGC=off make bench PKG=./pkg/util/tracing BENCHES=BenchmarkSpanCreation TESTFLAGS="-cpu=1,2,4,8,16,32 -count=5"

SpanCreation/detached-child=false     1.95µs ±28%  2.04µs ±24%     ~     (p=0.278 n=5+5)
SpanCreation/detached-child=false-2   1.32µs ±11%  1.23µs ±15%     ~     (p=0.310 n=5+5)
SpanCreation/detached-child=false-4   1.51µs ± 5%  0.81µs ±11%  -46.49%  (p=0.008 n=5+5)
SpanCreation/detached-child=false-8   1.86µs ± 2%  0.89µs ± 4%  -52.24%  (p=0.008 n=5+5)
SpanCreation/detached-child=false-16  2.08µs ± 5%  0.85µs ± 4%  -59.30%  (p=0.008 n=5+5)
SpanCreation/detached-child=false-32  2.21µs ± 2%  0.85µs ± 2%  -61.71%  (p=0.008 n=5+5)

---

For tactical reasons, this patch also adds protection for creating a
child span in a finished parent. This is illegal, as is any use of a
span after Finish(). Still, almost every other use of a span has
protection against use-after-Finish that makes the respective access
behave reasonably.  This protection will also act as a point where I'll
add an assertion, at least in tests, verifying the absence of such
illegal uses. So, this patch adds similar protection to creating a child
in a Finish()ed span.  In particular, it makes the new would-be child
span act as a root and be registered in the active spans registry.
Before, new span would be added to a finished parent, and so it would
essentially fall by the wayside and not make it to the registry.

Release note: None

Don't allow recordings to grow infinitely.

Release note: None