Add cats Eq/Order for Quantity

[cquiroz]

This is a first attempt at a coulomb-cats module. It contains now just the definitions of Eq and Order for Quantity[A, U]. Hopefully it can be expanded to get us Functor but I had some troubles on my attempts

It contains two modules: coulomb-cats contains the typeclasses and coulomb-testkit that contains Arbitrary and Cogen instances for test and discipline tests. If you prefer I could move the tests to coulomb-tests

[erikerlandson]

This looks good. One last nit is that the file name .../cats/package.scala is typically convention for the file defining a package-object. I'd name this file cats/implicits.scala

[erikerlandson]

Oh, can you add a file coulomb-cats/README.md? An example would be coulomb-refined/README.md - some information on how to include in project, maybe a couple short code examples

[cquiroz]

Just now that I'm writing the documentation I realize that Quantity already has a === operator. It makes me wonder if we really need Eq instances, though there are other uses of course like when using scalacheck

[erikerlandson]

I think there are potential use cases. I wanted "unit aware" comparisons but something like sorting an array is likely to be a case of comparing a collection of quantities having all the same value and unit types.

[cquiroz]

I added a readme and a few more test cases.
I move the package from coloumb.cats.implicits to coloumb.implicits. This is because often you import coloumb._ and the cats package would shadow the root cats package. Let me know if that seems ok

[erikerlandson]

This is because often you import coloumb._ and the cats package would shadow the root cats package.

That is a very interesting point. I have to assume this comes up for all of my integrations, as I have coulomb.refined, coulomb.pureconfig, etc. Currently I think this would be resolved via something like import _root_.pureconfig..., for example here.

In the immediate situation, what I propose is that we stick with coulomb.cats.implicits, and I suppose library users would then need import _root_.cats.implicits._ which is a bit of a hack but at least it is consistent with the rest of the coulomb integration packages.

In the longer term (a future coulomb-0.6 ?), this makes me want to re-think the package paths I am declaring, which would of course break some backward compatibility, but maybe some convention like import coulomb.integrations.cats... or perhaps invert it, like import cats.coulomb....

[cquiroz]

Ok it makes sense. It is a problem mostly if you try to import something from cats after coulomb

[cquiroz]

I'll update it

[cquiroz]

I moved the package back as suggested

[erikerlandson]

LGTM, Thanks @cquiroz!