refactor: fix statistics time

[kdrienCG]

This PR fixes some time misalignements in the statistics.

Statistics time label misaligned by one timestep, starting at t1 instead of t0.
Here is an example (resvol_constraint.xml) starting at t0 = 2500s while values correspond to the values in the XML input file (5000000 Pa pressure)

Time [s],Min pressure [Pa],Average pressure [Pa],Max pressure [Pa], ...
    2500,          5000000,              5000000,          5000000
    5000,          4571243,              4960905,          5264805
    7500,          4470766,              4951167,          5345129
   10000,          4428837,              4945246,          5381950
...

Now:

Time [s],Min pressure [Pa],Average pressure [Pa],Max pressure [Pa], ...
       0,          5000000,              5000000,          5000000
    2500,          4571243,              4960905,          5264805
    5000,          4470766,              4951167,          5345129
    7500,          4428837,              4945246,          5381950
   10000,          4398290,              4940123,          5408567
...

Details

Stats events previously used `time + dt` to label time and now uses `time + dt * eventProgress` to output the correct time at which statistics are launched/computed. `eventProgress` (always?) equals `0` in those cases, so stats basically run at `time = time`, but I added it if one day stats could launch/be computed at mid-event, I can remove it if it's not correct.

Statistics were missing the last timestep
Now statistics implements the ExecutableGroup::cleanup() to trigger a last execution, similar to other components such as VTKOutput, etc.

Details

Statistics were missing a last timestep, and some people had to modify the maxTime to maxTime + 1 dt to inspect the last timestep statistics.

This was the case in the testFlowStatistics.cpp file, which defined maxTime = 5500 instead of maxTime = 5000 (with 500s timesteps) to be able to output the last statistic.

[MelReyCG]

I suggest to abort this function if timestepId == 0 since flux statistics does not have any sense if we do not have any simulated timestep before.

[MelReyCG]

To preserve flexibility on the TableFunction values, I would check if time_n is the TableFunction coordinate at index timestepId, rather than having this linear timestepId * testSet.inputs.dt relation.