Rename execution contexts + improve their docs

[ysbaddaden]

As discussed in RFC 2 and in light of #15871 for example, the execution contexts are much more about "how fibers run", either concurrently or in parallel or by themselves (the intent), and have little to do with "threads" that are only the technical mean to achieve parallelism.

A great example is that the isolated context doesn't have the word thread in its name, despite being the only context that guarantees the fiber will always run on the same thread (the fiber owns the thread until it terminates).

This PR renames:

• SingleThreaded to Concurrent
• MultiThreaded to Parallel

It also refines the documentation of the different types to also insist on the intent, what it means, and what are the actual guarantees given by each context.

[straight-shoota]

As mentioned in #15946 (comment), I think we should keep the old names as aliases.
Even though we can't use the @[Deprecated] annotation, it at least avoids a hard break between 1.16 and 1.17, which is unpleasant if you want to test code with both releases, and maybe some nightlies in between.

[ysbaddaden]

I would consider it if the deprecation wasn't silent or the work around or patch was complex. It's trivial to fix. The whole feature is experimental for a reason: it's expected to break from version to version. We don't expect further changes in the public API. Let's break and be done with it.

EDIT: I added the deprecated aliases. See below.

[ysbaddaden]

Given #15962 I might revise my above opinion: the warning would no longer be silent, but gently loudly yell, and could be helpful to upgrade easily. Sadly it won't make it for 1.17 😭

EDIT: I added the deprecated aliases. The warnings shall be visible after #15962.

[straight-shoota]

#15962 won't make it into 1.17 due to the feature freeze. We could still merge this PR though because it only affects execution contexts, which are still an experimental API.
The deprecations wouldn't have any effect until compiler support becomes available in the following release (1.18).
We could then remove the deprecated features in 1.19 at the earliest.

[ysbaddaden]

@straight-shoota yes, we'll have deprecations in nightly then 1.18, and we can drop them in 1.19 👌

[zw963]

Should we update RFC0002 doc for this?