Draft: Strongly typed storage order

This MR tries to improve the handling of the storage order and the corresponding bit field. On the programmers side, a set of utility functions are introduced that make working with the storage order easier by hiding the details behind descriptive (at least I hope) function names.

There are three ways in which we handle the storage order currently.

1. As a boolean, to check if we are row/col major
2. As an entry in the a bit field.
3. As an enum with two possible values. There are utility functions for all three operations.

In order to make the third option really useful, and prevent accidental mix-up between these, we need the enum to not be implicitly convertible to int. For now, this MR creates a new enum class StorageOrder and changes all the template parameters that consider only storage order (i.e. not the full flags as in Matrix) to use this type.

I'm not completely sure how much breakage this would cause. Most of the struct that are changed are within namespace internal, but some are not, such as selfadjoint_rank1_update.

This change may have uncovered a potential bug in blas/level3_impl.h. In lines 365ff, I had to change the order of template parameters to get the compiler to accept the code, and I think the new order is the correct one. Could someone verify?