Support `Rational`, `Fixed` and perhaps `Scientific` via CBOR decimal fractions or binary fractions (big floats)

[dcoutts]

CBOR directly supports decimal and binary fractions. These are numbers represented as x*10^e or x*2^e. The mantissa 'x' can be a positive or negative small int or a CBOR big int. The exponent 'e' can only be a positive or negative small int (ie up to 64bit but not a big int)

And there is also an extension for rationals, ie x/y where both x and y can be small or big ints.

• We should use the CBOR decimal fraction for our Data.Fixed support. Currently we just encode the Integer mantissa and leave the exponent implicit in the type. It'd be better for debugging and data recovery if the exponent was also stored.
• We should use the CBOR rational extension for the Haskell Rational type.
• The Scientific type from the scientific package exactly corresponds to a CBOR decimal fraction, and we should encode it as such. (Of course where that instance should live is a good question).

It's not clear that we have any standard types that are best represented by binary fractions. We don't have a standard big float type.

[axman6]

I was going to give this issue a go, but wasn't sure what the best way to deal with the fact we already have an encoding for fixed - should we continue to support the current encoding and the CBOR decimal fraction encodings at the same, while encoding the latter? Also a similar question for Rational (though this is harder since we're dealing with Serialise a => Serialise (Ratio a) so we can't actually be sure that a will allow us to have a valid encoding according to the rationals extension. My Haskell extensions foo is failing me to think if there's a safe way to provide an instance for just Rational while keeping the Serialise a => Serialise (Ratio a) instance (without doing something crazy like providing a RULE).

[hvr]

@dcoutts as to where the Scientific instance shall live; IMO, either in scientific or in a cborg-instances package holding orphan instance. To me, packages providing typeclasses like cborg should try to stay as much as possible near the bottom of the dep-tree, similiar to binary or deepseq. This makes it easier to eventually have e.g. Cabal or GHC depend on it.