feat: Adaptive multilinear interpolation for OBL solver

[av-novikov]

This PR adds interfaces for embedding of Python function into C++ code, adds multilinear adaptive interpolation with given exact evaluator from Python and adds the support of both static and adaptive interpolation in ReactiveCompositionalMultiphaseOBLKernels. Ultimate goal is to run simulation similar to open-darts from a corresponding (part of) model given from Python.

• fix assembly in ReactiveCompositionalMultiphaseOBLKernels
• multilinear adaptive interpolation
• interfaces to call Python function from C++ (from interpolator)
• convergence test for multilinear adaptive interpolation
• generalize input of OBL fluid physics for static and adaptive interpolation
• pass Python-based OBL operators evaluator to solver
• use LvArray/src/python/PyFunc for embedding Python function to C++
• deduce access level in LvArray::python::PyArrayWrapper to support MODIFIABLE arguments: LvArray: PR 336
• unify casting-to-numpy interfaces between GEOS and open-darts: open-darts: MR 138
• Python interfaces to GEOS from Makutu repository: geosPythonPackages: PR 74
• Examples - 2ph_comp and carbonated_water (with PHREEQC-backed geochemistry) have been moved to geosPythonPackages: PR 74

FAQ:

Q: Why do we use __uint128_t ?
A: We need to count nodes and hypercubes in multidimensional state space. Even with 300 points per axis in 8-dim space (e.g. 8-component fluid), the number of points (300^8) surpasses the maximum of 64-bit integer. Moreover, single __uint128_t key type simplifies hashing points and hypercubes in std::unordered_map storage.

Q: Do we duplicate the storage of points?
A: Yes, because we minimize memory accesses by excessive, but consecutive storage.

[sframba]

Thanks @av-novikov for this PR! I think that the python scripts shouldn't go in a subfolder of compositionalMultiphaseFlow, but in a higher-level folder (maybe in a new folder scripts/pygeos?). We'll be adding the remaining Makutu scripts in the (possbly near) future and they'll be used for geophysics and potentially geomechanics workflows. All these base python classes and utilities need to be common to these other solvers as well. @CusiniM @rrsettgast what's your opinion?

[herve-gross]

@dkachuma @paveltomin can you help review this PR? Thanks.