Parallel Test: Flush fileBased Some

[ax3l]

Add an additional flush - which should be called implicitly anyway in the destructor - and which causes MPI issues.

Essentially what was added in #668

MPICH 3.3.2 error locally with ADIOS1 backend:

Fatal error in PMPI_Comm_dup: Other MPI error, error stack:
PMPI_Comm_dup(179)..................: MPI_Comm_dup(comm=0x84000002, new_comm=0x55c0ca44be1c) failed
PMPI_Comm_dup(164)..................: 
MPIR_Comm_dup_impl(57)..............: 
MPII_Comm_copy(571).................: 
MPIR_Get_contextid_sparse_group(495): 
MPIR_Allreduce_impl(293)............: 
MPIR_Allreduce_intra_auto(178)......: 
MPIR_Allreduce_intra_auto(84).......: 
MPIR_Bcast_impl(310)................: 
MPIR_Bcast_intra_auto(223)..........: 
MPIR_Bcast_intra_binomial(123)......: message sizes do not match across processes in the collective routine: Received 4 but expected 260

Weird: the MPI communicator is duplicated (and freed) in the ADIOS1 backend but not in the HDF5 and ADIOS2 backend.

[ax3l]

One should apply the same logic change to the serial ADIOS1 implementation. If I do so, than one already catches a problem that likely is now also present in the parallel version: as soon as flush() is called, some default attributes are written with default values if not yet changed by the users. That means, that after the first flush a user cannot change them anymore.
Not super-problematic if one writes meta-data (openPMD extension, record meta data, etc.) first before data, but not ideal either.

This is probably the reason for delaying attribute writes in this backend in the first place.

[ax3l]

If one removes this flush now, this test hangs in ParallelADIOS1IOHandlerImpl::open_write() (one rank) and in ~ParallelADIOS1IOHandlerImpl in MPI_Barrier(m_mpiComm); (the other rank)

[ax3l]

Looks like #674 could also fix this one :)

Backup of previous fix stored in branch topic-parallelSeriesPartialFlush-bakFix