remove float from the core shares calculation for LP + use shopsring decimal

[jeremyletang]

This is a fix for the state issue on testnet.

problem

The core calculate for each liquidity provider their share of the fees being paid. Using this share (a number between 0 and 1) we then multiply it against the total amount of fee to be paid per LP.
We then math.Floor the result of all these (share * fee to be paid) calculation, and give the rest (1 at most) to the last LP for which we paid the fee. Doing this ensure that we do not loose any pennies in the calculation.

This is very fine until we get a scenario where a float on some run / nodes fives a result in between 2 numbers (e.g sometimes: 127855.99999999999 and sometimes 127856) which would impact the actual flooring, and the rest to be distributed.

Amount of fee to be paid - 799100
Run 1

LP	AMOUNT	SHARE
0e432ed...09eb7c	95892	0.12
5f11bc7...cc7b7c	383568	0.48
a87f00d...c3497f	127855.99999999999	0.15999999999999998
dd2154a...7ba0a9	191784	0.24

Run 2

LP	AMOUNT	SHARE
0e432ed...09eb7c	95892.00000000001	0.12000000000000001
5f11bc7...cc7b7c	383568.00000000006	.48000000000000004
a87f00d...c3497f	127856	0.16
dd2154a...7ba0a9	191784.00000000003	0.24000000000000002

Adding all amount floored, give us for the run 1 a rest of 1, which is then distributed as part of the last party (dd2154a...7ba0a9). Adding all amount floored of the run 2 gives us the exact amoubt distributed, which do not requred to give the rest of 1 to the last party.

fix

We implemented all floating point calculation using a abitrary precision fixed point decimal number library for go (github.com/shopspring/decimal).

This will impact slighlty the performance, but will keep all calculation of fees correct over all the different nodes.

[EVODelavega]

Lots of debug to remove, still...