Uniquify implicit names

[non]

Paul Phillips mentions that in a widely-used library it's important to minimize the chance that the names of its implicits will be used by others. To that end I suggest that we review our implicits and rename them according to the following rules:

1. Make sure that the implicits start with cats -- it's less likely that a third-party will do this.
2. Make sure that both the type and the type class are mentioned in the name.

So for example, for Monoid[List[A]] the name should be something like catsMonoidForList or similar.

[non]

Since a single across-the-board PR is likely to conflict with every other open PR, we should either accomplish this piecemeal, or coordinate ahead of time. If you want to work on this issue please comment here so we can avoid duplicating work and plan for a minimum amount of conflict.

[ceedubs]

As an example of how name collisions can be problematic, in this gitter conversation, an upgrade from cats 0.5 to 0.6 broke someone's code because of a collision on the name listMonoid (they had created one for java.util.List).

[dwijnand]

Note that not only implicits that provide typeclass instances, but also syntax/enrich-my-type implicits suffer from the same exact problem.

A banal example is having two different implicit classes from different libraries called AnyOps.

Would this also be an issue for simulacrum generated implicits?
For example, for Invariant, we get implicit def toInvariantOps. Should that be implicit def toCatsFunctorInvariantOps?

N.B. Note the inclusion of the full package names, should this be standard as well?

[milessabin]

Would this also be an issue for simulacrum generated implicits?

Potentially yes.

Bear in mind that this can't be fixed by using freshName in a macro, because the names, even if they're never typed by a human, are public definitions and have to be stable between builds. There's some code in export-hook to deal with this.

[kailuowang]

I can work on this one. How about just tackle the std first?

[ceedubs]

@kailuowang do you think that this is done after #1066 and #1068? Or should we cover the other modules too? Collisions outside of the std package seem unlikely to me since people don't have to import the instances explicitly, but I guess there is something to be said about consistency.

[kailuowang]

I was thinking about doing syntax after the first two parts merged. I am out of the country now but i should be able to resume the work a week or so later.

[ceedubs]

@kailuowang ah, I hadn't thought about syntax - that sounds like an important one. Thank you!