Growing mesh case

[fsimonis]

This PR adds a growing mesh case.

Two solvers define the same mesh, which grows at given points in time.

Inspiration for this case is the formation of additional residue layers on the floor of an ocean over time.

@MakisH is this how you envision the separate solver folder to work?

Checklist:

• I added a summary of any user-facing changes (compared to the last release) in the changelog-entries/<PRnumber>.md.
• I will remember to squash-and-merge, providing a useful summary of the changes of this PR.

[MakisH]

I know that this is still a draft, but I had a quick look anyway, so I left some comments that I know are probably already on your list.

[MakisH]

We so far avoid calling participants and data generic names, but try to relate to a specific physical domain and application use case. This is currently only partially described in the naming conventions.

Of course, this is fine for now (and fine for an integration test), but before merging, we should better have more descriptive names.

[fsimonis]

They both represent the same mesh and don't model any physical behaviour.

Not sure what we would name them.

[uekerman]

There is a physical motivation for this scenario. We could borrow names there?

[fsimonis]

The pyhsical motivation is to couple a hydrogeological and geomechanical model and let them iterate until they agree on effective stress.
Without the iterative scheme, there is no correction and the geomechanical model doesn't have a function.

So, I cannot see obvious names that we can use here.

[MakisH]

But then we need to better express the motivation in the description and say that the modeling is (extremely) simplified, as is the case in general in our tutorials.

With the current formulation, it is a great integration test, but it looks a bit odd as a tutorial.

[fsimonis]

I added the motivation and more details about the solver.