runtime: improve the "best effort" of the execution tracer's CPU sample delivery

[rhysh]

The work in https://go.dev/cl/400795 (proposed for the Go 1.19 cycle) to add CPU profile samples to the execution tracer's output relies on the process generating at least a modest stream of other traceable events. If the process's goroutines as a group use more than 19 thread-seconds of CPU time before any individual P flushes a traceBuf (or before tracing ends), the profiling buffer will overflow and (silently) drop records before the goroutine calling runtime.ReadTrace wakes up to drain it.

There may be a better way to move profile samples from the profBuf into traceBufs (such as launching a goroutine to drain the profBuf).

[mknyszek]

See #58877 for a concrete example of the "best effort" falling over. (That issue was deduped with this one.)