Draft: New Problem interfaces for cvfe schemes (required for hybrid schemes)

What this MR does / why does DuMux need it:

Implements a new problem interface to get rid of discretization-dependent functions such as boundaryTypes(), dirichlet(...) and neumann() that dependent on scv or scvf.

Notes for the reviewer

I decided to put things in a new MR such that it is easier to discuss these changes. Once we agree on the new interface, I will undo changes that were made in the target branch, and which are no longer necessary due to the new problem class.

• We should discuss if we only want to have enableConstraints() or if we want to have another function enableInternalConstraints otherwise we check constraints for all elements also for interior ones.
• We need to discuss the handling of flux boundaries. Since the current implementation will no longer correctly work for higher order schemes where the basis functions related to fem dofs do not vanish on boundaries. See my comments below.
• More general, we should discuss which problem interfaces we want to provide. So far, dirichlet(...) and boundaryTypes(...) were discretization dependent. I think it would be better to make them purely dependent on geometry, e.g. dirichlet(fvGeometry, face, ipData). The discretization-dependent handling should be done in the assembly.
• Do we want to let the user define the type of FvIpData and FeIpData (for flux and source) in the problem class?
• Do we want to let the user define the type of a QuadratureRule (for flux and source) in the problem class?
• Discussion about VolumeVariables generalization

Before you request a review from someone, make sure to revise the following points:

• does the new code follow the style guide?
• do the test pipelines pass? (see guide on how to run pipelines for a merge request)
• is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
• does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in CHANGELOG.md.
• is the list of the header includes complete? ("include what you use")
• all files have to end with a \n character. Make sure there is no \ No newline at end of file comment in "Changes" of this MR.
• (if not applicable remove) are newly introduced or modified physical values/functions backed up with a scientific reference (including doi) in the docs?
• (if not applicable remove) if the examples are modified, is the documentation regenerated (using generate_example_docs.py)