Async[G] bound on AsyncFunctorK means certain instances are not implementable

[bpholt]

Including G: Async[G] in the definition of the asyncMapK method:

async-utils/core/src/main/scala/com/dwolla/util/async/AsyncFunctorK.scala

Lines 7 to 10 in 540fbcf

	trait AsyncFunctorK[F[_], G[_]] {
	def asyncMapK[Alg[_[_]] : FunctorK](alg: Alg[F])
	(implicit AlgR: Alg[ReaderT[F, Alg[F], *]], G: Async[G]): Alg[G]
	}

means that any types that cannot implement Async cannot be implemented for AsyncFunctorK either. I'm not sure how important this is, but for example, we can't implement a scala.concurrent.Future ~~> com.twitter.util.Future instance (or the reverse) since neither Async[Future] can be lawfully implemented.

If we'd moved the G[_] : Async context bound to the methods where the existing instances are defined, we'd at least be able to try implementing more instances. For example, at

async-utils/scala-futures/src/main/scala/com/dwolla/util/async/stdlib.scala

Lines 12 to 14 in 540fbcf

	implicit def scalaFutureAsyncFunctorK[F[_]]: Future ~~> F = new (Future ~~> F) {
	override def asyncMapK[Alg[_[_]] : FunctorK](alg: Alg[Future])
	(implicit AlgR: Alg[ReaderT[Future, Alg[Future], *]],

F[_] could be F[_] : Async, and the body of the asyncMapK method would remain unchanged.

AFAICT this cannot be changed in a binary-compatible way (applying the usual techniques still results in MiMa detecting a ReversedMissingMethodProblem), and I don't think this possibility is worth introducing a new major version on its own. If we need to release a new major version for some other reason, I'd like to consider including this refactoring as well.