Improve Blaze-interoperability of our matrix types

[nilsvu]

Feature request:

It would be nice to consolidate our matrix types and improve their interoperability with Blaze. Currently we have:

• DenseMatrix<Type, StorageOrder> : blaze::DynamicMatrix<Type, StorageOrder>: Exists to make a matrix option-creatable and pup-able.
• Matrix : DenseMatrix<double, blaze::columnMajor>: Exists only as a shortcut for a matrix of doubles in column-major storage order.

The types are subclasses (instead of aliases) so they can be forward-declared. Here are the problems with this setup:

• We are barely using Blaze features with matrices at all currently, e.g. compile-time sized matrices, sparse matrices, matrices of complex type, etc. For example, a spectral operation could reasonably be a blaze::HybridMatrix with max size determined by our max num points (not suggesting we actually do that, but it's a possibility).
• Functions like apply_matrices are built for Matrix. They should work for any dense column-major matrix of doubles, but currently don't. Also, Blaze has features to select the fastest available routine from LAPACK etc based on the matrix type at hand, which could improve performance compared to the explicit dgemv call that's currently in apply_matrices.

Similar issues apply to our vector types: We use our own custom DataVector a lot, but don't currently make use of Blaze features like grouping/tagging.

Does anyone have ideas how to improve interoperability with Blaze in our code? I've been thinking we could work more directly with Blaze types, but writing the blaze:: namespace all over the codebase seems like a bad idea since it couples us too tightly to Blaze. Perhaps we could do something like our tmpl namespace that's just an alias for brigand, e.g. linalg = blaze? I can't think of a great way how to organize includes and forward-decls in that case though.

[nilsdeppe]

1. I'm not sure it would be good to set it to max size. 12x12 is okay, but if someone increases that for testing they'll blow the stack pretty quickly. That seems like an bug. We also don't create matrices that often, they're usually cached and passed by reference. I regularly used 50+ basis functions for testing subcell, for example.
2. it uses dgemm_ calling into LIBXSMM. This is quite a bit faster than what Blaze does. If I remember correctly someone requested Blaze add LIBXSMM support a year or two back in an issue on the Blaze repo.

We do use grouping/tagging, just we used it before Blaze had official support for it. We could reasonably switch to using that in the backend, but this seems like it could be a lot of work with no benefit. I'm not sure what advantage Blaze's official grouping/tagging has over the under-the-hood stuff we use.

From this issue it's not clear to me what interoperability you are looking for. This seems like a question about why we don't use HybridMatrix, Blaze's operator* (or whatever the call to matrix multiplication is), and Blaze's grouping/tagging. What operation(s) are you trying to do that don't work?