task: add join_set::Builder for configuring JoinSet tasks

[hawkw]

Motivation

The JoinSet API controls the spawning of tasks on a JoinSet --- a
future is passed into one of JoinSet's spawn methods, rather than
having the user spawn the task on their own and pass a JoinHandle into
the JoinSet. This is intended to ensure forwards-compatibility with
potential future changes where a JoinSet might allocate new tasks
differently from how the public tokio::spawn and similar APIs do.
However, it means that JoinSet needs to have a number of API methods
for various ways of spawning a task, including on a LocalSet or via
a runtime Handle.

Currently, there is no way to use a task::Builder to configure a task
prior to spawning it on a JoinSet. This is a deficiency, as it means
that (unstable) task names cannot be added to tasks spawned on a
JoinSet.

See
#4535 (comment)
for details.

Solution

This branch introduces a new JoinSet::build_task() method that returns
a new join_set::Builder type. This type is a variant of
task::Builder which exposes a similar API, but it wraps both a
task::Builder and an &mut JoinSet, and spawns the built task on that
JoinSet.

I felt like this was the best approach from the perspective of the
user-facing API. It does require a bit of boilerplate code to duplicate
the task::Builder interface for the JoinSet::builder type, but I
think the interface presented to the user of the API is much nicer than
an approach where spawn_{whatever}_with_builder methods are added to
the JoinSet type. I discussed this a bit in this comment:
#4535 (comment)

This depends on #4683, which adds spawn_on methods to the
task::Builder API. These are necessary to implement JoinSet's spawn_on
methods using a task builder, but are also probably just generally useful.

[hawkw]

huh, seems like CI is kinda stuck on this for some reason...

[Darksonn]

Adding a builder instead of adding more and more variations of the different spawn methods seems like a good way to handle it.

[carllerche]

I think this is being pulled in from a different PR, but what about:

Builder::new()
    .handle(handle)
    .spawn(future)

[carllerche]

In discord, Alice points out that spawn_local requires a local set not a handle, so ^^ doesn't really work out.

[hawkw]

Yeah...there could be a trait of some kind that Handle and LocalSet implement, but that would be a bit of a public API commitment to make, I think...

[carllerche]

Generally looks fine to me. Couple of thoughts inline.