Feature/hld iofields

What this MR does / why does DuMux need it:

TODO: insert text here

Notes for the reviewer

TODO: insert text here

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)

doc/doxygen/highleveldocs/iofields.md

@@ -7,7 +7,8 @@ This class can used to add model specific output data to a custom @ref vtkoutput
 
 * initOutputModule():
     - Initialize a `vtkOutputModule` by specifying which variables shoud be written out and add the them via the function `addVolumeVariable()` to the `vtkOutputModule`.
-
+* primaryVariableName(int pvIdx, int state)
+    - returns the human readable name for the primary variable with index `pvIdx`. Models that do not use primary variable switching, will have always `state = 0`. In case of a primary variable switch (PVS) model, `state` has to be explicitly given when calling. Note that the state has to be known to correctly interpret the primary variables in case of a PVS model.
 ### Overview
 
 @mermaid{iofields}

[Timo Koch]

I'm taking this as an example sorry. I think descriptions like these will lead to a lot of duplicate documentation or a fragmented documentation. The respective function also has function documentation in the code. If the description here is better it should really be there.

But if you think mentioning these interfaces in the HLD is a huge benefit I would propose the following:

• If a base class or similar exists, simply reference that and copy its docstring

* VTKOutputModule::addVolumeVariables, @copydoc or @copybrief

• If a base/interface/default implementation class doesn't exist, create an archetype (https://en.cppreference.com/w/cpp/language/archetype) and document the interfaces and link to that.

• An alternative could be to link to all implementations by linking to a doxygen group and document that group and ingroup all implementations and combine this with @copybrief