[Core][AnalysisStage][DO NOT MERGE] InitializeSolutionStep() change in the order

[RiccardoRossi]

Small but profound change.

The idea is that InitializeSolutionStep of the solver should be called BEFORE applying BCs and Predicting
This makes no difference for most elements, but may be important for UpdatedLagrangian or Corotational elements

This branch is to discuss this.

[loumalouomega]

Blocking to avoid accidental merge

[philbucher]

tests in ContactApp segfault

[loumalouomega]

tests in ContactApp segfault

Probably I need to refactor the Contact NR

[RiccardoRossi]

I suspect that this is not specific of this PR.

tests are also giving an error in #6494 which seems to be unrelated to that PR

[loumalouomega]

I suspect that this is not specific of this PR.

tests are also giving an error in #6494 which seems to be unrelated to that PR

Those are different tests

[philbucher]

Those tests are in the CI and run all the time
If they fail I am 99% sure it is related to the corresponding PR

[maceligueta]

@KratosMultiphysics/dem just to be aware of this

[ddiezrod]

Not directly related, but I think the function "ApplyBoundaryConditions" is misleading as it calls also processes which have nothing to do with BCs and should probably be renamed..

[maceligueta]

I totally agree with @ddiezrod . It seems like ApplyBoundaryConditions is calling
ExecuteInitializeSolutionStep for all processes. These processes might be doing things that are not related to the boundary conditions.

[loumalouomega]

@RiccardoRossi many tests fail, not just the ones related with UL element, for example the ones related with displacement control

[philbucher]

I checked the CoSim tests with this and they worked
Still @KratosMultiphysics/cosimulation I suggest you try this also with your real examples