Symbolic coarsening of DirichletBC, and interpolate bc data from other spaces

[pbrubeck]

Description

The symbolic coarsening is happening because we would like DirichletBC to be refined symbolically in #4893. The symbolic and numeric coarsening are mathematically equivalent when the spaces are nested, but this is not the case for refinement. If we refined BCs numerically we would be appying the coarse BCs throughout the adaptive refinement loop, incurring great errors.

Since the symbolic boundary data might live on different function spaces, we need to add BCBase.coefficients() so that we can attach DM hooks to the function spaces of every coefficient in the problem and be able to extract the correct TransferManager of the problem.

This PR also enables prescribing BC data from a different FunctionSpace. Previously we were not allowing the data to be a pure Function on a different space, e.g. DirichletBC(V1, Function(V2), sub), but we allowed composite expressions with Functions on a different space, e.g. DirichletBC(V1, 2*Function(V2), sub). Here we allow both cases.

[connorjward]

Since the symbolic boundary data might live on different function spaces, we need to add BCBase.coefficients() so that we can attach DM hooks to the function spaces of every coefficient in the problem and be able to extract the correct TransferManager of the problem.

Not for this PR but I think that this needs cleaning up. This dmhooks business is getting quite out of hand. I plan on doing this at some point.

This PR also enables prescribing BC data from a different FunctionSpace. Previously we were not allowing the data to be a pure Function on a different space, e.g. DirichletBC(V1, Function(V2), sub), but we allowed composite expressions with Functions on a different space, e.g. DirichletBC(V1, 2*Function(V2), sub). Here we allow both cases.

Seems reasonable. This needs to be written down somewhere though. Both in a docstring and the manual.