chore: introduce an optimized integer compare algorithm for lists

[romange]

Problem: when lists are long OpRem will spend lots of time comparing an element with records in the list. For integer-based lists, most of the time is spent in lpCompare. In addition, lpGet has lots of branches that penalize integers use-cases.

This PR:

1. Introduces lpGet2 - the improved version with less branches.
2. Benchmarks lpCompare vs an algorithm that compares records to an integer.
3. Benchmarks lpGet vs lpGet2

On c7g:

----------------------------------------------------------
Benchmark                Time             CPU   Iterations
----------------------------------------------------------
BM_LpCompare          3068 ns         3068 ns      1844176                                                                                                                                                                                  
BM_LpCompareInt        705 ns          705 ns      8040593                                                                                                                                                                                  
BM_LpGet/1             385 ns          385 ns     14604564                                                                                                                                                                                  
BM_LpGet/2             309 ns          309 ns     18110999 

There are no functional changes to the Dragonfly code.
While by itself LpGet/2 is not worth the hassle, BM_LpCompareInt shows that comparing integers is significantly faster
than comparing strings

[BorysTheDev]

I think this part can be vectorized using the example x86 _mm_slli_epi16 instruction (maybe exist some extension for GCC or we can use separate intrinsic for arm and x86) also exist vector instructions that merge two int8 into int16 and 2 int16 into int32 etc

[romange]

I do not see what can be vectorized here.
The whole logic is around a single byte

[BorysTheDev]

I select too much, all shifts and OR operations like
uval = (uint64_t)p[1] | (uint64_t)p[2] << 8 | (uint64_t)p[3] << 16 | (uint64_t)p[4] << 24 |
(uint64_t)p[5] << 32 | (uint64_t)p[6] << 40 | (uint64_t)p[7] << 48 | (uint64_t)p[8] << 56;
negstart = (uint64_t)1<<63;
negmax = UINT64_MAX;

[romange]

if you paste it into godbolt you can see it has been compiled into a single load instruction. in any case, this is why I added micro benchmarks - to be able to iterate and improve if needed. I think it's fairly good as is.