Define policy for name collisions with Scala standard library

A number of cats methods collide with methods defined by the standard library, eg Functor.map, Foldable.foldRight. Because the cats' methods pimped onto a class have lower priority than methods defined on the class itself, the cats methods cannot be readily invoked using infix syntax. This can lead to the same operation name having different a implementation, and occasionally behaviour, for different container types:

@ Xor.right(1).map(_.toString) //via cats Functor typeclass
res9: Xor[Nothing, String] = Right(1)
@ Vector(1).map(_.toString) // via Vector or superclass method
res10: Vector[String] = Vector("1")
@ BitSet(1).map(_.toString) // via BitSet method, not Functor behavior
res11: SortedSet[String] = TreeSet("1")

It would help people writing applications on top of cats to have a clearly expressed policy around name collisions, or lack of, with the standard library. Two options are:

1. Coexistence through compatibility. Cats methods collide with the standard library, but so long as they do the same thing (almost all the time) its not a problem in practice. So any cats method sharing a method with scala collections API must have same behavior.
2. Non-collision. Cats methods never use the same name as the existing collections API. This has the benefit that it's obvious to library users whether they're using cats or std lib methods. It has the downside of requiring a big, disruptive change in the current cats api, and also means that many commonly used, intuitive names are off-limits, since they're taken by the std lib.

There may be other options? Whatever course is chosen, would be helpful to define the policy both for people (a) building on top of the library, and (b) adding methods to the api.

Start with the issue discussion and the collision examples involving Functor.map, Foldable.foldRight, Xor, Vector, and BitSet. Review the relevant cats methods alongside the Scala collections API, then determine what policy the project will document for library users and API contributors. Done means an agreed policy is recorded, including how matching behavior and naming should be handled.