Add templated memcpy/memcmp

[lnkuiper]

This PR adds templated versions of memcpy and memcmp, wrapped in methods called FastMemcpy and FastMemcmp, which select the specific templated version with a large switch statement.

The allows the compiler to pre-compile these functions with the specified number of bytes, and emit more optimized machine code. This yields a speedup specifically when these functions are used in a loop with a constant size, e.g.:

const size_t size = 8;
for (idx_t i = 0; i < n; i++) {
    // ...
    FastMemcpy(dest, source, size);
    // or
    FastMemcmp(str1, str2, size);
    // ...
}

The speedup can be up to 5-6x, depending on size.

Of course, these functions are heavily used in the sort code, and adding these functions yields a significant performance boost.
I sorted 100M random integers:

.timer on
.mode trash
create table test as select cast(random() * 99999999 as int) i from range(100000000);
-- pragma threads=1; OR pragma threads=4;
select * from test order by i;

And here are the results:

Threads	Old	New
1	4.285s	3.966s
4	2.968s	2.277s

As we can see, the performance is mostly felt when there are more threads, because it affects merge sort more than it affects radix sort.

The fun part is that the single threaded performance is now as fast as the 4 threaded performance on this specific benchmark was when the sorting blog came out.

[Alex-Monahan]

Wow, incredible that you've made that kind of improvement even after the initial algorithm change! Maybe it's worth re-posting the blog with a short update/new benchmark at the top?

[Mytherin]

Thanks for the PR! Looks good. Two questions:

[Mytherin]

If size%8 has to be 0, do we need to add the cases for size=1, size=2, etc?

[lnkuiper]

This can be removed but I forgot it was there, my bad. We may want to use this code elsewhere where the assertion does not hold.

[Mytherin]

Can't we just call memcpy with a variable size at this point?

[lnkuiper]

I found a slight performance improvement by calling the fixed memcpy like this beyond 256 bytes, that's why I kept it there. It's not much though. Would you prefer I change it?

[lnkuiper]

@Alex-Monahan That is a good idea. Maybe I should hold off on that until @Mytherin finishes the local storage rework that will allow for parallel creation of ordered tables?

These two things together will give a great performance boost, especially for strings.

[Alex-Monahan]

Even more goodies coming than I knew about!! :-)

[Mytherin]

Thanks!