Add support for column major slices

[jmh530]

mir-algorithm currently supports only row major slices. Adding optional support for column major slices, as in Eigen's template parameter approach, would provide a number of benefits, albeit at the cost of additional testing and work to set it up.

Column major slices can provide better data locality and memory access than row major slices, depending on the use case. For instance, an algorithm that loops through columns is faster with a column major order than a row major order, all else equal. Correspondingly, optionally column major slices would also be useful when working with dataframes, particularly with use cases related to tall data that are common in the R tidyverse or pandas.

Adding support for column major slices would also be useful for interacting with Fortran, R, Pandas, or other languages/frameworks that use column major arrays.

It would require a breaking change to change the definition of mir_slice from

struct mir_slice(Iterator_, size_t N_ = 1, SliceKind kind_ = Contiguous, Labels_...)

to something like

enum StorageOrder { Row, Column}
alias RowMajor = StorageOrder.Row;
alias ColumnMajor = StorageOrder.Column;
struct mir_slice(Iterator_, size_t N_ = 1, SliceKind kind_ = Contiguous, StorageOrder = RowMajor, Labels_...)

because D requires variadic templates to be at the end of the list. However, it shouldn't break code that relies on the Slice!(Iterator, N, kind) pattern so long as the underlying functions are set up properly.

As far as I can tell, the key thing would be adjusting functions like indexStride, but additional testing would be required to confirm everything works as expected for column major slices.

[9il]

Slices don't have raw-column major notation by design. It will require huge efforts to support it well in the code.

The benefits aren't so attractive. The reason is that raw-major matrixes can be used as column-major if we just think about them like about an array of columns. For example, mir-lapack.