[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. 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. (There is still a loop that remains for Int size smaller than 32 bits which I doubt ever happens. And if one wants, they can add another special case for 128 bits, but falling back to the 64-bit formula is at least correct)
• 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 single-word values that don't fit an Int (between 2^63 and 2^64).

Added a benchmark suite. With this we are faster than pack . show across the board.

All
  Builder
    decInteger
      Txt64:   OK
        1.52 μs ±  97 ns
      Str64:   OK
        2.22 μs ± 141 ns
      Txt6400: OK
        190  μs ±  13 μs
      Str6400: OK
        210  μs ±  10 μs
    hexInteger
      Txt64:   OK
        1.01 μs ±  12 ns
      Str64:   OK
        5.21 μs ± 158 ns
      Txt6400: OK
        161  μs ±  13 μs
      Str6400: OK
        3.45 ms ± 227 μs

[Bodigrim]

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