Cleanup of SolverGMRES and SolverFGMRES implementations

[kronbichler]

This PR does three major cleanup steps in the SolverGMRES and SolverFGMRES implementation:

• Make SolverFGMRES also use the Givens rotations for the orthogonalization, rather than the Householder transformation. (This changes a few tests to slightly lower iterations, I checked that the real residual is correct.) This is achieved by making the Givens rotation a free function.
• Use more similar variable names in both solvers to more easily understand them both. In particular, choose inner_iteration as the name for the inner iteration, rather than dim (mixed into it) or j.
• Make the size of the basis the default of SolverGMRES::AdditionalData. We had a todo by Guido for a long time, and I think it is time to make this change now. This also helps the similarity between the classes. Note that this can affect tests, where I opted for changing the parameter where necessary.

If this finds approval, I will write a changelog.

[peterrum]

If this finds approval, I will write a changelog.

I am in favor 👍

[kronbichler]

I now added two changelog entries, one describing the incompatible choice for the size of the Arnoldi basis and one for the algorithmic change in the SolverFGMRES. Regarding the former, I do not see another way than letting the new max_basis_size take precedence, even though I anticipate that some users might set additional_data.max_n_tmp_vectors = xx; in a separate statement, that would now be invalidated by the value of max_basis_size in the constructor. Otherwise, I would have to guess what the user intended, e.g. letting max_n_tmp_vectors take precedence whenever max_basis_size is set to 30, but how can I know that this comes from the default constructor of SolverGMRES::AdditionalData than something the user wants to happen? Thus, let us simply make the incompatible change now.

[peterrum]

The usage of # is the first I see it. Do we need it? SolverGMRES does not and still creates a link in Doxygen.

[kronbichler]

I copied it from somewhere else in this file and then just went with it by routine; thinking about it I will remove it, thanks.

[kronbichler]

Any additional comments on this PR? I would like to finalize this one soon, because #16749 sits on top of this branch and things get messy if they diverge too much (there is already some tiny deviation).

[masterleinad]

Looks good to me. I would maybe also be fine with removing max_n_tmp_vectors already since we can't deprecate it properly anyway.