Allow different boundary composition plugins on different boundaries

[gassmoeller]

This sits on top of #2051, and implements the same functionality. The one extension is the fact that there are several compositional fields (compared to only one temperature field).

I figured out a way to allow users to prescribe different boundary conditions for different fields, but I have run into problems with the sparsity pattern of the matrix, because we currently reuse the same matrix block for all compositions. Different boundary conditions would constrain different entries in that block, and so we can not any longer eliminate those entries (because I might need them for another composition).
@tjhei or @bangerth: Did I understand that correctly, and does the change that I made to the sparsity pattern solve this by keeping those matrix entries (core.cc:1088 and 1097)?

@anne-glerum: Could you check if this covers all of the application cases you had in mind? I would also be grateful if you could play around with the boundary conditions and see if something breaks during parsing complicated cases (i.e. some boundary conditions for some fields, others for others, and no boundary conditions for other fields).

Also I still need to figure out what breaks in the discontinuous tests.

[tjhei]

@tjhei or @bangerth: Did I understand that correctly, and does the change that I made to the sparsity pattern solve this by keeping those matrix entries (core.cc:1088 and 1097)?

Correct, but the disadvantage is that this will add a lot of nonzero entries in all matrix blocks (especially painful for velocities). I don't know how much of a difference that makes, but I assume we can have 10%+ constrained DoFs in an adaptive computation. @bangerth , what do you think?

I have to play with this a bit, but we should be able to only set this flag for the compositional field matrix where it doesn't matter as much.

[gassmoeller]

For now I disabled the option to have boundary conditions at a particular boundary for one field, but not another. It is still possible to use different plugins for different fields, but if one field has a prescribed boundary, all of them have to as well. Keeping the constrained dofs seemed to work for the compositions, but then I got errors during the assembly of the Stokes system of the type 'trying to access non-existent matrix entries'. I can look into how to keep constrained dofs for some components only at a later time, but for now we can go forward with this PR (adding the new functionality later will be backward compatible. This is ready from my side.

[gassmoeller]

Let us put this on hold for after the relase. @jdannberg and I discussed a plan to make this change backwards compatible, so it is just another feature. Essentially by introducing a new parameter name, we can support both the old and new versions to set boundary conditions.

[bangerth]

@gassmoeller: What's the status here? Can you rebase and should I then take a look?