[Lysxia]

Close #713

• The main source of inefficiency in integer seems to be repeated branches to test whether we are in base 10 or base 16. They probably get in the way of further simplification. This is solved by parameterizing integer by everything that depends on the bases upfront.
• The other reason is that the constants maxInt and maxDigits were computed in a loop, which prevents inlining them and wastes a register to store them. We replace them with more direct formulas that can be computed at compile time.
• Use Word instead of Int to contain chunks of digits, simplifying the formula for maxDigits.
• In go, I removed the first branch n < maxInt because it turns out the second also handles this case correctly, just with an extra multiplication and division. This is only a slight pessimization for a thin subset of integers that don't fit an Int (between 2^63 and 2^64).

Added a benchmark suite. With this we are competive with toLazyText . fromString . show (which is faster than pack . show BTW) for decimal conversion and much faster for hexadecimal conversion but that's because it's quadratic (showHex).

All
  Builder
    decInteger
      Txt64:   OK
        1.17 μs ±  86 ns
      Str64:   OK
        1.20 μs ±  36 ns
      Txt6400: OK
        158  μs ±  13 μs
      Str6400: OK
        145  μs ±  11 μs
    hexInteger
      Txt64:   OK
        1.26 μs ±  83 ns
      Str64:   OK
        4.31 μs ± 341 ns
      Txt6400: OK
        158  μs ± 7.8 μs
      Str6400: OK
        3.08 ms ± 193 μs

[Bodigrim]

macOS needs to be pinned to 15 instead of latest, if you want to fix CI prior to merging.