Adds distributed row gatherer

[MarcelKoch]

This PR adds a distributed row gatherer. This operator essentially provides the communication required in our matrix apply.

Besides the normal apply (which is blocking), it also provides two asynchronous calls. One version has an additional workspace parameter which is used as send buffer. This version can be called multiple times without restrictions, if different workspaces are used for each call. The other version doesn't have a workspace parameter, and instead uses an internal buffer. As a consequence, this function can only be called a second time, if the request of the previous call has been waited on. Otherwise, this function will throw.

This is the second part of splitting up #1546.

It also introduces some intermediate changes, which could be extracted out beforehand:

• a type-erased DenseCache
• makingdetail::run easier to use now part of Use index_map in distributed::matrix #1544

PR Stack:

• Add specific communicator for neighborhood communication (Again) #1780
• Add local to global index mapping #1707
• Use Index map in PGM #1639
• Adds distributed row gatherer #1589

[MarcelKoch]

One issue that I have is the constructor. It takes a collective_communicator and an index_map. The index_map already defines the communication pattern, so the collective_communicator has to match that.
One option might be to have a virtual function like

std::unique_ptr<collective_communicator> create_with_same_type(communicator, index_map);

If I can't come up with anything better, I guess I will use that.

[pratikvn]

Do we need to have the std::future setup for the release ? Can we remove that for now and just use a normal synchronous approach ? I think that is a significant change that maybe needs more thought and probably a separate PR.

[MarcelKoch]

@pratikvn, @yhmtsai I've removed the row gatherer from the LinOp hierarchy for now. It instead directly derives from PolymorphicObject. You might want to give it a second look because of that.
The reasoning for me was that the apply will always create temporary clones for the vectors, using the executor from the operator. However, in the case of non-GPU aware MPI, this will always lead to throwing an exception, because then the output vector will always be on the device.
I think it should be possible to handle this correctly with generalized MPI request, but this might take quite a while for me to realize, so I would rather proceed as it is.