fix: bug fix for precision handling

[squirer]

Purpose

Integer parsing between CBOR Positive(u64) and CBOR negative(u64) - added float check for finite numbers and documented api that 15-16 significant digit floats are advised to use Json string representation.

Changes

Added unit tests and further documentation for boundary number processing

Checklist

• My code follows the style of this project.
• The code compiles without warnings.
• I have performed a self-review of the changes.
• I have documented my code, in particular the intent of the
  hard-to-understand areas.
• (If necessary) I have updated the CHANGELOG.

[squirer]

@allanbrondum @andynelson

i have now updated the solution with the agreement of treating the numbers as u64, i64 and f64 based on our discussions. Also updated the tests now to show that we support i64 MIN > u64 max for literals, everything else falls back to f64 and the only ever produced is if a float is provided with a way too large exponent for example: 1e400.

So our documented range now is:

• we support literals between i64 and u64 range: -9223372036854775808 and 18446744073709551615
• we support f64 with out of the box behaviour of precision to 15 or 16 significant digits.

Here is the transaction proof for tesnet for how these values are respected:

• i64 min test : -9223372036854775808
  hash: 65c960c046ebfcfb6c92f64779ab7fdb9085af372822a148412a2cb7c56410de
  ccd scan shows parsed number: -9223372036854775808
  link: https://testnet.ccdscan.io/transactions?dcount=1&dentity=transaction&dhash=65c960c046ebfcfb6c92f64779ab7fdb9085af372822a148412a2cb7c56410de

• u64 max test: 18446744073709551615
  hash: 83b5fd6d028cb8dfa44b1530b38a2bd38fe4fd19356c77a67444fd3d0568f087
  ccdscan shows correct parsed number: 18446744073709551615
  link: https://testnet.ccdscan.io/transactions?dcount=1&dentity=transaction&dhash=83b5fd6d028cb8dfa44b1530b38a2bd38fe4fd19356c77a67444fd3d0568f087

• float with 14 digits after decimal point, 2 before: 99.99999999999999
  hash: 0b157362c61225cfeabaf2e1bb775f869e9f920c67e82425423ca8f4cfda4a12
  precision accurate: https://testnet.ccdscan.io/transactions?dcount=1&dentity=transaction&dhash=0b157362c61225cfeabaf2e1bb775f869e9f920c67e82425423ca8f4cfda4a12

• float with 15 digits after decimal point, 2 before: 99.999999999999999
  hash: eb077f3937f365648fdeec82bc3934ebb866cba4aa1f101b60de52a6273753d5
  Precision lost here, number reflected as 100:
  https://testnet.ccdscan.io/transactions?dcount=1&dentity=transaction&dhash=eb077f3937f365648fdeec82bc3934ebb866cba4aa1f101b60de52a6273753d5

• Normal float: 1.0
  hash: c10f1c58be19a3b8eb8bb870ee0c2315127d11e9caec593d7b373a8aa9ed7d52
  ccdscan parses as 1 instead of 1.0 but concordium client says it is recorded correctl as Cbor float:
  link: https://testnet.ccdscan.io/transactions?dcount=1&dentity=transaction&dhash=c10f1c58be19a3b8eb8bb870ee0c2315127d11e9caec593d7b373a8aa9ed7d52

So i believe we are all good here with the changes now contained in this PR.