Wip sip23 √

@viktorklang 

>> but that is not the point of capture -- the point of capture is to save context at the site of suspension, not execute
> 
> Could you define that so that a user of ExecutionContext knows what to do? And we still need to address the testability and fragility of "if prepare is not called things break, but nobody knows when to call it or how many times".
>
> This is the (sad) ScalaDoc for prepare:
> "Prepares for the execution of a task. Returns the prepared execution context. A valid implementation of prepare is one that simply returns this."
> 
> May I propose that we completely disregard prepare and capture for now, and instead focus on finding the optimal solution to the problem (taking into consideration performance, usability and reliability).

Absolutely. This was the original design goal for `prepare`, but obviously this failed. (Though I still believe it's fixable by introducing staging explicitly in EC's type as discussed above.)

First, here's what I would have formulated the documentation:

"Prepare should be called at the site where an `ExecutionContext` is received (for example, through an implicit method parameter). The returned execution context may then be used to executable tasks. The role of prepare is to save any context relevant to an execution's *call site* so that it this context may be restored at the *execution* site. (These are often different: for example, Promises may suspend execution until the promise is fulfilled, which may be done in another thread, on another stack.)"

It's clear that the `prepare` mechanism is in support of context switching. Maybe this should be explicit in the choice of names. Ideally this mechanism would even be completely divorced from `ExecutionContext`, but I believe then it is even more fragile: anyone defining what amounts to a context switch would have to remember to call this API. This, to me, was the value of building it in to `ExecutionContext`.

So, for a moment, let's disregard backwards compatibility and discuss: what would be the best solution, API wise, for this? My take is something like we discussed above (sketch):

```
trait ExecutionContext {
  protected def execute(r: Runnable)
  /** Excellent docs. */
  def save(): Runnable => ()
}
```
then I wager an implementor wouldn't simply default to:

```
ec.save().apply(r)
```

because they'd ask themselves: "save? that's weird, maybe I should look up the docs."

(But I have been wrong about this before.)