Prevent SOE on Stream traverse with Future

As title says.
It isn't just about it making it work on `Stream`, but rather have it work correctly while still being parallel. This problem does not exist when we simply use the default `ap` which sequences the `Future`s through `bind`. The goal of this fix is to have the parallel `ap` behave like the sequential, `bind`-based `ap`, while still running its arguments in parallel. The fix does exactly that :)

@ceedubs Basically, I looked at how `ap` was working in `Bind`, then wanted to replicate the "trampolining" effect that it allows. Namely, the `bind`-based implementation of `ap` forces `fab`, but pushes the evaluation of `fa` into the `Future`'s `flatMap`. Since we don't want to sequence the effects, we instead just `flatMap` it in an "empty" `Future` that will evaluate relatively quickly, but still allow the trampolining effect. Unfortunately, it does require an extra thunk to scheduled on the threadpool.

I'm going to throw up some benchmarks in a second, but first I just want to reiterate that this PR is just trying to ensure that code that wouldn't SOE with a `bind`-based `ap` also doesn't SOE with this parallel `ap`. It is purely about ensuring these 2 cases are equivalent. I think, based on that merit alone, it deserves to stay.