Julia: Split up long running tests some more

[Keno]

We have some rather long-running tests, particularly on slow machines (e.g. KNL). It would be good to split those up some more. The worst offenders (from a KNL run):

linalg/diagonal (14)        |  510.55  |  1.72  |  0.3 | 1700.32    | 338.29
bitarray (76)               |  526.51  |  2.81  |  0.5 | 2722.84    | 394.37
linalg/qr (3)               |  570.19  |  3.46  |  0.6 | 3087.33    | 377.35
arrayops (66)               |  569.20  |  3.80  |  0.7 | 2473.68    | 485.29
linalg/lq (22)              |  576.79  |  1.86  |  0.3 | 3036.09    | 378.71
parallel (146)              |  669.16  |  0.00  |  0.0 |  5.18      | 237.79
sparse/sparse (27)          |  711.90  | 70.70  |  9.9 | 2044.43    | 418.86
linalg/dense (4)            |  801.39  |  3.59  |  0.4 | 3180.17    | 388.57
sparse/higherorderfns (29)  |  804.48  |  3.51  |  0.4 | 3512.64    | 434.74
sparse/sparsevector (28)    |  881.77  |  2.81  |  0.3 | 2846.67    | 389.55
linalg/arnoldi (25)         |  991.20  |  1.59  |  0.2 | 1185.46    | 318.51
linalg/matmul (5)           | 1403.10  |  1.89  |  0.1 | 2363.30    | 357.77
subarray (26)               | 1450.06  | 16.15  |  1.1 | 8445.22    | 633.14
linalg/triangular (2)       | 2040.71  | 28.97  |  1.4 | 10229.32   | 603.94

Would be good to split up everything over 500s or so. For extra credit, keep these in the same file, but have some mechanism to declare a split.

[kshyatt]

bitarray is a great candidate for easy splitting into multiple files.

[andreasnoack]

For the linear algebra tests, most of the time is spent on compilation so there is a risk that splitting up the tests further will increase the runtime on systems with less than 68 cores.

[jamesonquinn]

https://github.com/JuliaLang/julia/pull/20965 starts this... if this looks good, I'll keep doing it.

[jamesonquinn]

Looks as if the subarray test has the same issue as @andreasnoack points out for the linalg tests; that is, it's easy to split it into independent parts that are 261s and 24s, but if you split the 261 down further it doubles up the compile time so it ends up something like 212s + 123s. By Grabthar's hammer, not a savings.

https://github.com/jamesonquinn/julia/commit/63ab2c98a432f381288ea5bd5d410b947d8e4d7d

[vtjnash]

Most of these don't live in base anymore, but would still be helpful to accelerate subarray and LinearAlgebra/triangular.

On a fast machine, they are also fairly fast (although for most of these, these are taking 50-100% longer relative to v0.6):

LinearAlgebra/lq                   (23) |   122.95 |   4.02 |  3.3 |    8651.06 |   467.38
LinearAlgebra/cholesky             (18) |   139.23 |   4.70 |  3.4 |    8497.99 |   445.31
LinearAlgebra/qr                    (6) |   143.60 |   5.08 |  3.5 |   11303.82 |   479.75
arrayops                            (4) |   148.44 |   5.54 |  3.7 |    9501.56 |   563.62
LinearAlgebra/symmetric            (20) |   154.05 |   6.28 |  4.1 |    8986.13 |   480.07
LinearAlgebra/lu                   (19) |   163.19 |   6.38 |  3.9 |   10007.54 |   596.23
SparseArrays/higherorderfns        (30) |   178.93 |   5.30 |  3.0 |   11513.60 |   514.69
bitarray                            (3) |   181.67 |   8.08 |  4.4 |   14436.54 |   581.09
LinearAlgebra/diagonal             (17) |   195.54 |   8.28 |  4.2 |   12599.68 |   552.64
Distributed                        (33) |   221.23 |   0.11 |  0.0 |     104.62 |   254.42
SparseArrays/sparse                (31) |   234.80 |  27.84 | 11.9 |   11139.17 |   514.40
LinearAlgebra/dense                 (7) |   238.17 |  10.94 |  4.6 |   16697.73 |   642.14
SparseArrays/sparsevector          (32) |   257.01 |   6.54 |  2.5 |   18519.66 |   694.23
subarray                            (2) |   280.98 |  20.68 |  7.4 |   26307.72 |   961.28
LinearAlgebra/triangular            (5) |   515.49 |  28.89 |  5.6 |   38497.61 |  1159.73