Remove default behavior from non-affine pullback.

[jorgensd]

Currently the non-affine pullback termination criterion for the Newton solver is not exposed, leading to several people having issues with convergence on non-affine geometries (https://fenicsproject.discourse.group/t/newton-method-failed-to-converge-for-non-affine-geometry-when-evaluating-the-function/11653/8?u=dokken).

In general, we would like people to be able to access these arguments when doing their stuff, such as Function::eval and interpolate_nonmatching.

This PR removes the default arguments from the C++ layer, and only introduce them at the top-level routines in the Python-API.

[jhale]

This looks good, but why have divergent interfaces between Python and C++? If it is not reasonable to set defaults in C++, then the same probably applies in Python.

[jorgensd]

This looks good, but why have divergent interfaces between Python and C++? If it is not reasonable to set defaults in C++, then the same probably applies in Python.

In general, C++ users are considered as expert users, while Python users (even if they fill 98 % of the users) usually get default values. Especially as these parameters are only used on not-affine geometries, I find it a bit intrusive to force users to add them in Python if they work on affine simplicies.

[jhale]

I don't really follow the argument which relates choice of programming language to a user's level of expertise. I would note that the user on Discourse seems to be using Python.

Your base argument is sound - if the defaults are not actually useful, i.e. they are things that the user needs to be made aware of for the algorithm to work reliably, then they need to be passed. Reasonable starting points can be suggested in the docstring.

[jorgensd]

I don't really follow the argument which relates choice of programming language to a user's level of expertise. I would note that the user on Discourse seems to be using Python.

Your base argument is sound - if the defaults are not actually useful, i.e. they are things that the user needs to be made aware of for the algorithm to work reliably, then they need to be passed. Reasonable starting points can be suggested in the docstring.

The main reasoning for supplying these as default arguments is that they are only relevant for non-simplex geometries, they have no effect on simplex geometries, as the pullback is affine.
With that in mind, I would say we should have default arguments in the lowermost C++ interface.
However, I know @garth-wells doesn't like default args, and is why I have chosen to have them only in the Python API.