Suggestion: swap argument ordering of dolfinx_mpc.assemble_vector to coincide with the ordering of dolfinx.fem.petsc.assemble_vector

[avharbick]

Title basically says my suggestion. I was writing some code using a periodic boundary constraint and wanted to test something without the constraint. I copied and pasted the code, modified the boundary conditions and removed references to the mpc. Doing this the code ran but every solution was going to zero after a single solve. It took me entirely too long to realize that this was because the places where I was assembling the rhs vectors were using assemble_vector(<form>, <vector_to_write>), and this was (at least for me) leading to dolfinx.fem.petsc.assemble_vector returning a vector of nans, since that function normally anticipates the order assemble_vector(<vector_to_write>,<form>).

If there is a specific reason for the ordering of arguments in dolfinx_mpc.assemble_vector then it is what it is, but it might be a good quality of life change to swap the order to be dolfinx_mpc.assemble_vector(<vector_to_write>, <constraint>, <form>), just so that it has the same ordering of the vector and form arguments as the fem.petsc version, and it would hopefully prevent future unfortunate souls like myself from getting it mixed up.

[jorgensd]

It is a good suggestion.
The main reason for it being as it is, is that I didn't want to use @singledispatch at the time.