More flexible material property storage

[timofeymukha]

We have a very simple type for material properties now, that basically stores the rho, mu, cp and lambda. Once we have more than one scalar, this does not really work out. Furthermore, right now the material_properties type parses the material properties in the case file and then we pass this object to the schemes. However, if we adopt a "everything is a simcomp" it will probably be a reversed relationship, as currently seen in PR #1129 . So we basically need a way for a simcomp to add the properties to the material_properties type, which will then act as a database.

One way could be using a json_file object. Each scheme could then add a subobject with the appropriate subcomponents giving something like

{
"fluid" : {"rho": 1, "mu": 1e-6},
"temperature" : {"cp": 1, "lambda": 1e-2},
}

However, we don't really use json_file for anything but the parameter file and its bits. Are we fine with further extending its use to store runtime generated data?

[njansson]

My only concern is if we need to traverse the json object each time wee ned to retrieve e.g. $\lambda$, otherwise it's nice if it describes the case, even at runtime

[timofeymukha]

Should happen when "communication" between simcomps is necessary, I guess, e.g. for the scalar to get the fluid's density. Afterwards it is stored in the scheme. Then again this whole thing totally breaks if density e.g. becomes variable, so a field :-). Maybe we don't need this broker material_properties type at all. One needs to give some thought on how simcomps "communicate" with each other.