Remove the `f.semi()` requirement from ContinuableFuture.

[brycelelbach]

Hey @LeeHowes,

I think this was added in a recent merge request - ContinuableFuture now requires a semi() method.

Why do we need to have this? I don't think this is something we've previously discussed. We talked about putting this on the polymorphic concrete wrapper types, but not on the concept.

This either adds burden to future authors, or isn't particularly useful. ContinuableFuture is a refinement of SemiFuture, so I imagine a lot of people (myself included) will write futures like this:

struct my_future
{
  template <typename Executor>
  auto via(Executor&& exec) &&;

  template <typename Continuation>
  auto then(Continuation&& c) &&; 
};

Now if I have to add semi(), what do I do? This?

struct my_future
{
  template <typename Executor>
  auto via(Executor&& exec) &&;

  template <typename Continuation>
  auto then(Continuation&& c) &&;

  my_future semi() { return *this; }
};

Am I supposed to return something that is ONLY a SemiFuture? If so, then I have to write a whole class for nothing.

If the intent is that I'm supposed to return something that is ONLY a SemiFuture, that's an odd requirement that doesn't work with the wording today, and I think would require more discussion

I'd like to axe this, please. I'm open to discussing it later, but I don't want to include this requirement in version 1.