Mention {mirai} in {future} docs

[jcheng5]

Sorry @shikokuchuo, I just realized I had these changes sitting locally, uncommitted. I thought I had published this ages ago.

[shikokuchuo]

Thanks Joe!

My first thoughts on those bullets are:

3. mirai actually has a general interface for launching remote workers and is being used on Slurm clusters, for example this community-contributed example. I know that future is designed to be a general API, but I'm not sure that actually translates into it being able to be used in more places.
4. I think the key here is that mirai is queued, so nested topologies automatically work without having to carefully manage them like future - so this is definitely a positive for mirai, but doesn't quite read as such!

I also think it's definitely worth mentioning that:

• mirai promises are event-driven rather than polling (much more efficient, lower latency)

The following may tie into 4 above, that mirai is inherently queued:

• mirai is always non-blocking and doesn't require the use of future_promise()

Hope the above makes sense for you. I'd be happy to suggest wording, but I also don't want to put words in your mouth! Let me know what you prefer or if you have any questions on the above.

[jcheng5]

Please feel free to edit. I don't even know what I wrote, this was months ago!

[shikokuchuo]

Please feel free to edit. I don't even know what I wrote, this was months ago!

Thanks Joe, I've gone ahead and added suggestions. Please feel free to re-word any of them. If there's anything I can make clearer for you do feel free to ask!

[shikokuchuo]

@jcheng5 I've added a final point about task cancellation. It would be good to get this merged. Thanks!

[jcheng5]

Took some messing around with the version number (initially the updated docs only went to the /dev/ URL path), but it's updated now.

[shikokuchuo]

Thanks!