High-Level Particle Patches

Particle Patches should get a high-level interface for convenient usage.

The data type is fixed for number of particles and offset in the particle array and can be as attributes taken for the position "offset" and "extent".

I am thinking of something a `Patch` object and an API like:
```C++
// for 123 particles, decomposed in x
// x and y range: [0.:123.)x[0.:123.), equally distributed
Patch patch0(
{10, 0}, // uint64_t numParticles & numParticlesOffset
{{0., 0.}, {10., 123.}} // T offset & T extent in position
);
Patch patch1(
{113, 10}, // uint64_t numParticles & numParticlesOffset
{{10., 0.}, {113., 123.}} // T offset & T extent in position
);
// of course as well with default constructor and setter/getters

electrons.particlePatches.reset( 2 );
// patch ID needs to be consistent if multiple MPI processes write those
// in MPI reality, two ways are possible
// after an MPI_Scan, only the master process writes those
// or each process writes at its MPI_Rank index
// or every Nth process writes N patches ...
// so counting the add()s locally would not be sufficient

electrons.particlePatches.add(0, patch0); // or insert or ...
electrons.particlePatches.add(1, patch1);
```

Also, we need a `load()` method that returns a list/vector of all patches. Particle patches are small records, users will need them only *at once* during reads, so we can remove the `load( idx )` signature. -> done in #364

Note: Also in general, `idx` must not be shown to users during load. They shall handle patches as list of unsorted patches without any implicit order which would cause a lot of confusion. E.g. users must not assume that their MPI_Rank after a restart/between different jobs stays the same in the chosen domain decomposition, which is a big rabbit hole of errors one can make.

During refactoring, I think a `ParticleRecordComponent` should not inherit from a `BaseRecordComponent` but from a regular `RecordComponent` as well: we want for example support for constant records components in patches.