Add FunctorK trait

[diesalbla]

There are several transformers and data types in cats and associated libraries that are parameterised on a kind-1 type F[_] and a kind-0 type parameter A. For convenience, I called them the effect type and the value type, respectively. Some of these data types are Nested, EitherT, OptionT, OneAnd, Kleisli, Free.

In cats-tagless project defines a trait FunctorK, for types that provide a mapK method, which could be defined as follows:

trait FunctorK[A[_[_]]]  {
  def mapK[F[_], G[_]](af: A[F])(fk: F ~> G): A[G]
}

The proposal of this issue is to bring the definition of this FunctorK type-class into the core library, given that it would abstract an operation already in the library.

[LukaJCB]

For some history on this:
#1982
#1815
#1620

[LukaJCB]

@diesalbla FWIW, I don't think we need to close this immediatly, we could discuss this again :)

[djspiewak]

As a quick intuition as to why this has historically been complicated…

Higher-kinded arities get complicated very quickly. The FunctorK defined in the OP issue here is pretty intuitive, and there are a lot of inhabitants, but it isn't strictly the higher-order version of Functor in the way that InjectK is the higher-order version of Inject, or MonoidK is the higher-order version of Monoid. There are very valid reasons why you would want a different signature (see #1815), but that sort of signature in turn rules out some nice applications of the OP's signature, particularly if you care at all about type inference.

It's kind of a mess. Poly kinds make this much nicer. Also if Scala had a kind system which didn't encode arities in the way it does, that would also make these sorts of things easier to generalize (since we wouldn't have to carry an explicit first-order-kinded type along as we climb the universes).

[kailuowang]

@djspiewak thanks for the helpful summarization of the problem. I am going to refer to it at the FunctorK definition in cats-tagless.