Improve matrix_assembly_data performance

[upsj]

We could make the performance of matrix_assembly_data much better by building a row-wise flat hash map ourselves. For that we only need an upper bound for the number of columns for each row (either individual or a global upper bound). The access could be implemented in a thread-safe fashion (atomicCAS on the column indices, atomicAdd on the values) or single-threaded fashion (non-atomic access to the column indices)
If we wanted to build an unbounded hash map, we could collect elements exceeding the size bounds in a global "overflow" hash map, but that would probably be harder to do in a thread-safe fashion.

[MarcelKoch]

I think Dune has some interesting ideas on how to assemble matrices. Here is the documentation of their approaches: https://dune-project.org/doxygen/2.10.0/classDune_1_1BCRSMatrix.html#details

[upsj]

I believe we might be talking about different concepts of matrix assembly here. The documentation you attached seems to be focused more on assembling the sparsity pattern (with the values being set once, no duplicates), while our concept is more about collecting values (with multiple values being added together). Once the sparsity pattern is assembled, we can use something like csr_lookup or a matrix representation of the sum_duplicates operation to implement the actual assembly.