Add support for 256 bit JSON numbers (vs. strings)

[matthew1001]

This PR is related to firefly-signer PR hyperledger/firefly-signer#76 and it provides support for large JSON numbers being handled by FireFly.

Most usage of Ethereum (and this library) includes use of large integers greater than 64bits in size.
For example ERC-20 tokens are often deployed using 18 digits of precision so "1 token" is 1000000000000000000.

The FireFly APIs are designed for this, and support supplying this data as strings in JSON, using decimal or hex numeric form. This is the safest way to pass information through JSON as many code implementations in various languages (including Golang by default) do not support serialization/parsing of JSON numbers larger than the safe Javascript maximum (2^53-1) or the safe float64 maximum. They also might lose precision on serialization/de-serialization.

However, the JSON number notation is capable of representing large numbers without the loss of precision.

FireFly currently limits JSON number input params to 64 bits in size. For Ethereum data types such as uint256, this prevents you being able to invoke/deploy smart contracts with params up to max-size(uint256).

So this issue is very specific to the use of JSON number (not JSON string) parameters

This PR uses json.NewDecoder() with UseNumber() within the existing fftypes.Unmarhsal() function to treat large numbers as json.Number, not float64. This does not affect unmarshalling strings or smaller size integers.

[peterbroadhurst]

This change has a potentially wide big scope due to the generic nature of the JSONAny type, so I've been 🤔 hard about it.

The one case I believe that would be broken by this is:

var myVariable int64
myStruct.JSONAnyField.Unmarshal(ctx, &myVariable)

Before that would have worked, but I wonder now if Go will complain?

Either way, I'm convinced we can go forwards with this one.

[EnriqueL8]

@peterbroadhurst Did you mean float64 instead of int64 given the UseNumber only applies to float64

[matthew1001]

This change has a potentially wide big scope due to the generic nature of the JSONAny type, so I've been 🤔 hard about it.

The one case I believe that would be broken by this is:

var myVariable int64
myStruct.JSONAnyField.Unmarshal(ctx, &myVariable)

Before that would have worked, but I wonder now if Go will complain?

Either way, I'm convinced we can go forwards with this one.

I've added some extra checks to my new unit test (with both int64 and float64 variable types for completeness). Interestingly the decoded.Decode() behaviour with UseNumber() enabled appears to be to silently accept the precision loss and let you unmarshal to a float64. I'm not sure this is helpful so I've added an explicit check and a new error message if you attempt to unmarshal to a float64.

If you feel the better behaviour would be the previous behaviour of accepting the unmarshal request and potentially losing precision I'm happy to remove my new error.

[peterbroadhurst]

This is great. No concerns from me.
I don't have any knowledge of a particular consumer of this library that will be affected, and it's good news that if they exist they'd be very unlikely to notice a very subtle change.

(They'd be better off using types like ethtypes.HexUint64 than a straight int64 or float64)