ApplicativeError's `orElse` should accept widening?

With the exception of the new (as of Cats 1.2) orElse in ApplicativeError, most other places (including in the Cats library) that have an orElse allow the widening of its second parameter.

The traditional signature of an orElse for ApplicativeError would be

def orElse[AA >: A](other: ⇒ F[AA])(implicit F: ApplicativeError[F, E]): F[AA]

This is currently preventing me from upgrading to Cats 1.2, because my own orElse is no longer being picked up. I don't find any discussion of using this uncommonly restrictive signature in #2243: was this just an accidental oversight. I wanted to trigger the discussion about whether the Cats signature was wrong before I go work around this in my own code.

I'm not sure if this change can be made without breaking binary compatibility, but I can submit a PR if there's interest. I think the current signature is undesirable.

Start with the ApplicativeError.orElse signature described in the issue and compare it with the widening signatures for Validated and Either. Check whether changing the second parameter to accept a supertype preserves binary compatibility; done means the API decision is resolved and the Cats 1.2 behavior no longer blocks the reported upgrade.