Wip sip23 √

@mariusaeriksen, @viktorklang - here's some background: https://groups.google.com/d/msg/scala-sips/fh2kSQI5Q_M/7jRte4BsEBUJ

The problem is that `prepare` has very onerous rules about when and where it should be called. Currently `prepare` requires capturing and recapturing at every callsite.

You might call `prepare` correctly in 99% of your library methods, but if you call it wrong or forget to call it, then your code will sometimes break. It's really, really easy to get wrong. [E.g. here are four bugs in Scala's Future!](https://issues.scala-lang.org/browse/SI-7846)

Regarding introducing another type, here's what I said in my scala-sips email:

> Errors are difficult to spot, because prepared and unprepared `ExecutionContext`s both have the same type and so are indistinguishable to both compiler and programmer. The unprepared `ExecutionContext`, which should not be used, is also implicit within the method's scope, so it's incredibly easy to use accidentally.

But now I'm not convinced we really need another type, we just need to get `prepare` out of `ExecutionContext`. If we did have another type then I'd suggest that the new type should have the `prepare` method while `ExecutionContext` would retain the `execute` method so that it can be used for execution by existing libraries. (So that's different from [your example](https://github.com/viktorklang/scala/pull/6/files#r14365577) where you have `ExecutionContext` doing the preparing.)

I guess this type would look something like the following.

```scala
trait ExecutionContextPreparer {
  /** Import the prepare method if you want automatic capturing, otherwise prepare manually. */
  implicit def prepare: ExecutionContext
}
```

Like I said, I'm not convinced we want this type. It's easy enough for a third party library to write this code themselves, and not at all necessary for interop. I'm satisfied with just deprecating `prepare` on the `ExecutionContext` itself.