1888/precision handling

[MarcelKoch]

This PR adds runtime precision handling to LinOp. A new enum is created to provide the precision at runtime. The precision enum has values for all supported value types (depending on the cmake configuration). Additionally, it has the two values none and any. none is used to denote missing precision information or an invalid state. The any value can be used for mixed-precision applications.

The precision is stored in the LinOp class. Each existing linop sets the correct precision. There are helper variables to map a compile time type to a runtime enum value.

The opposite map is available by creating a variant from the enum.

[yhmtsai]

could you elaborate more on the precision?
currently, it mostly translate ValueType in template to runtime.
FFT with any, but it actually only accepts complex float and complex double
Jacobi with valuetype, but it can store different precision inside.
Is there any place other than default advanced apply_impl using that out of the concrete class scope?
in the concrete class scope, we can always grab runtime variable from template.

[MarcelKoch]

could you elaborate more on the precision?
currently, it mostly translate ValueType in template to runtime.

Yes, that's mostly the goal. It essentially allows the as_precision mechanism for the abstract multivector interface.

FFT with any, but it actually only accepts complex float and complex double
Jacobi with valuetype, but it can store different precision inside.

These two are the outliers we currently have. Here speaking of precision of the operator doesn't make much sense. I think rather it's about the vector precision the operator can be applied to.
Maybe for operators it should better be get_compatible_precision[s]. This could fix the issues with FFT and Jacobi.

Is there any place other than default advanced apply_impl using that out of the concrete class scope?
in the concrete class scope, we can always grab runtime variable from template.

I think you are right. In the current usages, we have the compile type available (except the generic linop advanced apply, which could be moved back to each class).
But I still think we need to have a runtime type available. For the multivector interface we could have as_precision<ValueType>, but this needs still to call a non-templated virtual function. So we need to translate between compile time and runtime type anyway.