CommutativeGroup for BigDecimal isn't actually commutative

…but only since you can observe the MathContext it carries along with it:

scala> import cats.implicits._, java.math.MathContext
import cats.implicits._
import java.math.MathContext

scala> val zero = BigDecimal("0")
zero: scala.math.BigDecimal = 0

scala> val zeroU = BigDecimal("0", MathContext.UNLIMITED)
zeroU: scala.math.BigDecimal = 0

scala> (zero |+| zeroU).mc
res0: java.math.MathContext = precision=34 roundingMode=HALF_EVEN

scala> (zeroU |+| zero).mc
res1: java.math.MathContext = precision=0 roundingMode=HALF_UP

This isn't cool, but I'm also not sure it's a major emergency, or even that it needs to be fixed, for a few reasons:

• The current behavior is the same as the standard library's and will be expected by many users. Changing it to enforce commutativity is likely to break at least some users' expectations.
• Java's BigDecimal (which Scala's BigDecimal wraps) doesn't have a MathContext attached to instances at all, and many users of Scala's BigDecimal use it in that way.
• Our Eq instances for BigDecimal don't compare MathContext, so with respect to Cats's idea of equality for BigDecimals the instance actually is commutative.

@johnynek has argued in #3303 that we should do one of two things:

• Define an ordering on MathContext and use that (probably via the max) in our implicit CommutativeGroup for BigDecimal.
• Remove the implicit CommutativeGroup instance (possibly leaving an implicit Group with no commutativity guarantee, I guess?) and provide a method that takes a MathContext and returns a
  CommutativeGroup[BigDecimal].

If we do this we should probably also change our Eq instance for BigDecimal to make it compare the MathContexts (at least in our tests).

My vote is not to do anything, since that's the least likely to surprise users and doesn't seem terribly inconsistent to me, but I wanted to make sure all the options are on the table.

Start by locating the implicit CommutativeGroup and Eq instances for Scala BigDecimal and reproduce the MathContext examples from the issue. Review the alternatives described in the discussion, including ordering MathContext or removing the implicit instance. Done requires a decided compatibility-preserving behavior and corresponding tests, but the issue does not specify which option to implement.