Co-Authored-By: Dilum Aluthge <dilum@aluthge.com>

Sorting used to be okay for booleans, but radix sort messed with the
dispatch and made it up to 6 times slower in the worst edge case. Rather
than deal with that dispatch, I added compile time dispatch to a
specialized boolean sorting routine that works on arbitrary orderings
and is twice as fast as what was previously in base.

This is mostly noticable for lengths 257-1999 because they were
previously dispatched to comparrison sort, skipping dispatch to
sort_int_range!

Also add comments.

…t_int_range!

Because a) indexing with a Bool is not valid and b) specialized Bool sorting is faster

2.5% speedup on `@belapsed sort!(x) setup=(x=rand(Int, 2001))`

…ges to help the code match the explanation

radix_sort! is not exported and only called with Int lo and hi values, 
so changing the eltype of counts to UInt should have no exported impact. 
I made this change 
a) to simplify slightly
b) because unsigned fails for BitInt
c) because line 715 can now overflow as of the previous commit, and if 
we are using a custom integer type, that might error.

unsigned(hi-lo) gives a false illusion of generality.

ln -> lenm1
mn -> v_min
mx -> v_max
rln -> v_range
umn -> u_min
umx -> u_max
urln -> u_range

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>

`@inbounds` is a 1.8x speedup for sorting trues(10_000)

I couldn't verify performance gains from making CHUNK_SIZE and MASK known at compile time, so I'm trying to resist the urge to abuse the compiler.
I also noticed this was 20% slower than SortingAlgorithms.jl's RadixSort for `@belapsed sort!(x) setup=(x=rand(Int, 3000000)) evals=1` because it used a chunk size of 13 which is too high. On my computer the best chunk size for that case is 10, and I couldn't find a size where higher than 10 was better than 10. Once I set max chunk size to 10, the 20% regression turned into a 2.5% regression, well within margin of error.

…ation) in cases where the existing methods are already very fast (i.e. short int range and short vectors)

notes:
source len ratio (>1 is regression)
S = sort R = reverse a = almost
float  40   .87
Int    40   .96
1:40   40  1.07
1:20   40  1.7
1:3    40  2.61
1:2    40  1.92
1:1    40  1.72
(1.734)
S Int  40   .92
R Int  40   .92
aS Int 40   .84
aR Int 40   .93
(.9027)
aR flo 40   .89
aS flo 40   .73
S floa 40   .77
R floa 40   .81
(.7979)

to address regressions for sorting reverse sorted or almost reverse 
sorted data. Detection cost 2-7%, only impacting sorting vectors longer 
than 40 and shorter than 3bits (e.g. `rand(Int, 100)`).

Also put in all same detection for 128 bit types under direct order 
(free).

`Serial` -> nothing, `serialize` -> `uint_map`, `deserialize` -> 
`uint_unmap`, `Serializable` -> `UIntMappable`?

Co-authored-by: Milan Bouchet-Valat <nalimilan@club.fr>