runtime: refactor goroutine profilerecord types

[austinderek]

Previously, goroutine profiles were collected into two adjacent slices
each of length n, with the i'th index of the first holding the captured
stack of the i'th goroutine and the i'th index of the second holding its
captured labels.

This changes the representation used during collection to be a single
slice of length n, with the stack and labels of the i'th goroutine now
residing in two fields of each struct in that slice.

Switching from multiple slices each of a single attribute each to one
slice of multiple attributes avoids allocating multiple slices, as well
as needing to pass them both around, side-by-side, in all goroutine
profile collection code. While maintaining and passing two slices was
workable -- if perhaps slightly cumbersome -- passing side-by-side around
would quickly become unwieldy if or when any additional attributes such
as wait reasons or wait times are collected during goroutine profiling,
for example as proposed in golang#74954.

Regardless of the user-facing shape that any such extension to goroutine
profiling may end up taking, this updated internal representation should
be substantially easier to extend and maintain than side-by-side slices.

This is a pure refactor of this internal representation; it should have
no user-facing behavior change.

While in the area: concurrent goroutine collection has been the only
mechanism used for some time now, so the disused legacy implementation
goroutineProfileWithLabelsSync is removed and the single remaining
implementation is renamed to drop its 'concurrent' qualifier.

Updates golang#74954.

Change-Id: I3fd14834b2f3aae73317d3fad3294d539302713f

---

🔄 This is a mirror of upstream PR golang#76141