Add Tolerance for numeric instances in Kernel

Yes...This will be a big issue for binary compatibility, so now that is out of the way...

Currently there is an instance for CommutativeGroup[BigDecimal] in kernel.

We know that Double and Float are not associative.

As BigDecimal is also not associative, even if it is more almost so than Double and Float, the suggestion is that we deprecate this instance, and move it to Alleycats.

A recent travis-ci build from @barambani proved this:

[info] Tests:
[info] - CommutativeGroup[BigDecimal].commutativeGroup.associative *** FAILED ***
[info]   GeneratorDrivenPropertyCheckFailedException was thrown during property evaluation.
[info]    (Discipline.scala:14)
[info]     Falsified after 97 successful property evaluations.
[info]     Location: (Discipline.scala:14)
[info]     Occurred when passed generated values (
[info]       arg0 = -2.8417959213202718E-297,
[info]       arg1 = -1.1849307132157056E-298,
[info]       arg2 = 8.389487697470448E-273
[info]     )
[info]     Label of failing property:
[info]       Expected: 8.389487697470447999999997039711008E-273
[info]   Received: 8.389487697470447999999997039711007E-273
[info] ScalaTest

This will also impact algebra, so /CC @denisrosset @johnynek, who could, of course, choose to use the proposed alleycats instance instead.

Start with kernel/src/main/scala/cats/kernel/instances/bigDecimal.scala and the associative law reference in kernel-laws/src/test/scala/cats/kernel/laws/LawTests.scala. Compare the related implementation in algebra/core/src/main/scala/algebra/instances/bigDecimal.scala and review the issue discussion for binary-compatibility constraints. Done means the BigDecimal instance treatment is resolved consistently across the affected projects.