Make .sort about 4.4x as fast on Int/Str/Num arrays

AlexDaniel++ expressed concern about the Junction check causing a
slow down in sorting.  And he was right.  However, when looking at
the profile, it occurred to me that most of the overhead of sorting
was caused by using the default infix:<cmp> logic.  With the multi
sub "compare" now inbetween, it was possible to turn this overhead
into a feature by adding additional candidates for Int/Str/Num and
their allomorph counterparts, and just having the nqp::cmp_x in
there.  This basically made this benchmark:

    my @A = ^1000 .reverse; for ^100 { @a.sort }

go 4.4x as fast, mostly caused by the fact that the code went down
from 12 GC's to 0, and of course one less sub to be called, and no
coercion from Order to int being necessary anymore.

src/core.c/Rakudo/Sorting.pm6

@@ -1,3 +1,6 @@
+my class IntStr { ... }
+my class NumStr { ... }
+
 my class Rakudo::Sorting {
 
     # Return new IterationBuffer with the two given values
@@ -27,6 +30,11 @@ my class Rakudo::Sorting {
           for       => "as a value when sorting",
         ).throw
     }
+    multi sub compare(IntStr:D $a, IntStr:D $b) is raw { nqp::cmp_I($a,$b) }
+    multi sub compare(   Int:D $a,    Int:D $b) is raw { nqp::cmp_I($a,$b) }
+    multi sub compare(   Str:D $a,    Str:D $b) is raw { nqp::cmp_s($a,$b) }
+    multi sub compare(NumStr:D $a, NumStr:D $b) is raw { nqp::cmp_n($a,$b) }
+    multi sub compare(   Num:D $a,    Num:D $b) is raw { nqp::cmp_n($a,$b) }
     multi sub compare(\a, \b) { a cmp b }
 
     # https://en.wikipedia.org/wiki/Merge_sort#Bottom-up_implementation