This code necessarily has to have some sort of inexact conversion. That's rather the point -- we shouldn't be assuming that money calculations are integer arithmetic! So assume that CMoney is implemented using some sort of exact rational arithmetic bignum library. How do we then write code that converts CMoney into an (compact!) ASCII-comparable string, in a way that is code-compatible regardless of the underlying integer type?

A reasonable compromise is what is implemented here -- reduce, if necessary, to the precision of a double and then use the newly added `EncodeDouble` to convert *that* into a sortable `uint64_t`. Note that this is 100% consistent with current behavior in bitcoin - `double` provides 2^53 bits of precision, where `MoneyRange` constrains maximum value to less than 2^52.

I respect the gut-instinct "eww" attached to floating point conversion. But in this case it's actually a reasonable compromise.