Use conductivity interface to remove code duplication

[gassmoeller]

This PR is an example of what will be possible when #6211 is merged. Currently the material models Steinberger and Entropy use the same thermal conductivity model, either constant or a temperature-pressure dependent approximation. In order to do that they duplicate the code incl. declaration and parsing of parameters. In this PR I outsourced all of that to the new thermal conductivity plugins and either use the plugin Constant or TosiStackhouse depending on user input. Ultimately I want to get to the state where the thermal conductivity plugins form their own plugin system, where the user can select from the input file which plugin to use (ideally for most or all material models).

[jdannberg]

Are you still working on this? I went though the PR, but I think while I did, you removed the constant plugin...

Anyway, this looks good to me, the only question I had was:
In all other plugin systems (EOS, viscosity, reactions) we compute the property for separately for each point. Here you decided to compute the conductivity for all points in the material model inputs. Why did you think that was the right choice?

[jdannberg]

Suggested change

	* observations". The thermal conductivity is constant or following a
	* observations". The thermal conductivity is constant or follows a

[jdannberg]

A question: The viscosity and eos plugins (and the reaction models as well) compute their properties inside the loop over all points, whereas your conductivity is outside and makes its own loop. Is this on purpose?

This of course has advantages and disadvantages of what one can do with it.

[jdannberg]

Is that related?

[jdannberg]

Suggested change

	* A class that implements a pressure and temperature-dependent thermal conductivity
	* A class that implements a pressure- and temperature-dependent thermal conductivity

[jdannberg]

Suggested change

	* Parameters for the temperature- and pressure dependence of the
	* Parameters for the temperature and pressure dependence of the

[gassmoeller]

Thanks for the review, I have addressed all the minor comments.

A question: The viscosity and eos plugins (and the reaction models as well) compute their properties inside the loop over all points, whereas your conductivity is outside and makes its own loop. Is this on purpose?
This of course has advantages and disadvantages of what one can do with it.

Yes, you are right that this is handled differently than for the equation of state and the rheology plugins. I am still unsure about the best path forward here, but I think in retrospect the decision to let equation of state and rheology compute properties for one point at a time was a mistake. The current interfaces to the EoS and rheology plugins often look like this:

      ViscoPlastic<dim>::
      calculate_isostrain_viscosities (const MaterialModel::MaterialModelInputs<dim> &in,
                                       const unsigned int i,
...

where in contains inputs for all points, and i determines which point should be computed at the moment. This is awkward, if input for all points is handed over, why not immediately compute all points? Our reasoning back then (I think) was that we wanted to keep the phase functions and the task of averaging the different phases out of the individual plugins, and let the material model handle this, but I dont recall how this is exactly connected.

Anyway, we already use the interface I propose here for the reaction model (in grain_size_evolution.cc and katz_2003_mantle_melting.cc), so both types of interfaces already exist.

We should probably have a discussion about which interface is more useful in the long run. Is it ok to move forward with this PR in the meantime (given that #6211 has already introduced the inferface and this PR just adds one more plugin)?