Transient multiapp catch up does not properly catch up when one app has to run a longer time in first step

[GiudGiud]

Bug Description

A common simulation technique in multiphysics is to start solves at different times, so that at t=0s they are all synchronized and at steady state

However, if catch_up = true, the catching up only tries to match the main app dt, not catch up in time so that the apps synchornize. In this case we want to be using sub_cycling

But if we dont want that, then it still fails to realize it's caught up with its initial objective as this logic fails:

                  if (ex->getTime() + app_time_offset +
                          (ex->timestepTol() * std::abs(ex->getTime())) >=
                      target_time)
                    caught_up = true

target_time is based on main app time there is no app_time_offset since we dont want the apps to remain disynchronized ex->getTime() is in the subapp time

Steps to Reproduce

Start subapp with start_time = -20 Set catch_up = true Do not set a global time offset. If you set a global time offset, that means you want the app times not to synchronize, to stay offset

Impact

Ugly initialization transient on MSFR coupled inputs happened and should not have