Filter NaN flows from MIP

Please check if the PR fulfills these requirements

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

When sensitivity computation in PRAO fails for a given contingency, a sensitivity failure over-cost is computed, but the flow CNECs of that contingency are still part of the MIP range-action optimization. This leads to NaN values in MIP (when sensi computation fails, output reference flow value is NaN) and can crash the RAO.
When the initial sensitivity computation has a failed state, no overcost is reported

What is the new behavior (if this is a feature change)?

MIP fillers that use the flow variable now filter flow CNECs first, and only retains those with a succeeded sensitivity computation status
Unfortunately, since the status can change between two sensi iterations, we may have to remove or add variables and constraints. Since removing variables and constraints is not possible in OR-Tools, the linear problem's update method now resets the MIP and calls the "fill" method first
PR https://github.com/powsybl/powsybl-open-rao/pull/994 has been reverted since it is no longer necessary
An extra security has been added in OpenRaoMPSolver in order to prevent the MIP from running when there are NaN values added
When the initial sensitivity computation has a failed state, the overcost is now reported. This means the RAO can prefer RAs that remove network divergence.
The OpenRaoMPSolver (that uses OR-Tools under the hood) is now used in unit tests, making the tests more representative of real-time execution. However, some numerical tolerances had to be relaxed in consequence
Also, because we have to reset MIP and call "fill" then "update" when updating now, we cannot access values used in iteration N-1 when in iteration N. Thus MaxLoopFlowFiller and MaxMinMarginFiller cannot keep values from iteration N-1 anymore (when PTDF should not be updated with PSTs). It is assumed that the updated or not values are handled outside the fillers

Does this PR introduce a breaking change or deprecate an API?

Other information

This patch allows avoiding NaN values while keeping the actual fill / update APIs. But it does make updateBetweenSensiIterations almost useless, so we will have to refactor the code to remove all updateBetweenSensi methods and replace them with the creation of all-new problems
It seems that overamm performance is not really impacted by the re-creation of the optimisation problem between sensi computations. But we'll have to keep an eye on the metrics.

powsybl / powsybl-open-rao