Unroll varint reading loops

[anthony-swirldslabs]

As demonstrated at #797 , unrolling loops in our current varint reading implementation can significantly improve the performance. See the PR for an example of the code.

[anthony-swirldslabs]

Note that adding limit checks after processing each byte reduces the performance significantly:

Benchmark                                         (range)   Mode  Cnt     Score    Error   Units
VarIntByteArrayReadBench.loopLess                       1  thrpt   15  3069.126 ± 24.809  ops/us
VarIntByteArrayReadBench.loopLess                       2  thrpt   15  1816.447 ± 20.423  ops/us
VarIntByteArrayReadBench.loopLess                       3  thrpt   15  1119.635 ±  4.420  ops/us
VarIntByteArrayReadBench.loopLess                       4  thrpt   15   959.847 ±  1.757  ops/us
VarIntByteArrayReadBench.loopLess                       5  thrpt   15   795.254 ±  4.126  ops/us
VarIntByteArrayReadBench.loopLess_withLimitCheck        1  thrpt   15  3092.287 ± 20.485  ops/us
VarIntByteArrayReadBench.loopLess_withLimitCheck        2  thrpt   15  1095.908 ±  1.608  ops/us
VarIntByteArrayReadBench.loopLess_withLimitCheck        3  thrpt   15   799.257 ±  1.775  ops/us
VarIntByteArrayReadBench.loopLess_withLimitCheck        4  thrpt   15   588.538 ±  1.445  ops/us
VarIntByteArrayReadBench.loopLess_withLimitCheck        5  thrpt   15   478.348 ±  7.305  ops/us

which makes sense because the code becomes very similar to what the regular algorithm with loops does.

Therefore, to preserve the performance gain, we must create dedicated versions for each specific limit. Note that this is only possible when the limit can be determined upfront (e.g. with arrays and buffers). When processing a stream of data, this is impossible to do, and hence we'll have to pay the price of limit checks for streams.