Fix yoyo and flat router collision

[Minchan-Kwon]

This PR resolves the incompatibility between the yoyo algorithm and flat routing.
Through my hold time benchmarks, we have discovered that the yoyo algorithm is capable of fixing inter-cluster hold violations, but struggle with intra-cluster violations. We presumed a combination of yoyo and flat routing could improve intra-cluster hold violations. However, using yoyo and flat routing exposed an error described in issue #3728.

What this fixes

1. NaN crash in route_budgets.cpp

A pin that is connected to a constant generator (vcc/gnd) gets an infinite slack because a constant signal doesn't "arrive" relative to a clock edge. route_budgets::calculate_clb_pin_slack() already properly handles this infinite slack when flat routing is off, by setting the slack to a finite upper bound if there are no other finite values available. However, it didn't go through the same logic when the flat router was turned on. The infinite value here goes to minimax_PERT(), where it could be divided by another infinite delay value, causing a NaN error.
Fix: If the slack value is infinite, curr_min_slack remains at its initial value it was given at declaration (delay_upper_bound), aligning with what the non-flat router already did.

2. Actual yoyo and flat routing collision

The cost function for yoyo compute_node_cost_using_rcv() called get_expected_delay_and_cong(), which didn't check for is_flat_ and only handled cluster-level wiring (CHANX/CHANY). So it would not work with flat routing because it had no concept of the primitive-level intra-cluster nodes. The non-yoyo path get_expected_cost() didn't have this problem as it checks for is_flat_ and calls get_expected_cost_flat_router() which correctly identifies intra-cluster nodes.
Fix: get_expected_delay_and_cong() (the function yoyo calls) now checks is_flat_, and branches to either get_expected_delay_and_cong_flat_router() or the renamed get_expected_delay_and_cong_global() (the original inter-cluster routing logic).
Yoyo also requires separate delay and congestion costs, so get_expected_delay_and_cong_flat_router() returns the two values separately for yoyo+flat_routing and get_expected_cost_flat_router() is a thin wrapper that sums the two values, used when RCV isn't active.

Results on the hold benchmarks

Test results on the hold benchmarks show that the combination of yoyo and flat routing improves hold time optimization. With yoyo only, VPR fails to route all three circuits when the clock uncertainty is 300ps or higher. However, when yoyo is used with the flat router, VPR succeeds in routing the basic.v uncertainty circuit (a simple two-FF design) for uncertainties up to 500ps. It also succeeds in routing FFT.v and MATMUL.v (more complex, heterogeneous designs) at a 300ps uncertainty, although it does fail at 400ps.
I am not certain whether this failure is due to a limitation of the router algorithm or the circuits simply being physically unroutable at the given uncertainty value. Nevertheless, the results show that yoyo and flat routing allows VPR to successfully route a larger set of hold problems than using yoyo alone.

Limitations

• The --routing_budgets_algorithm yoyo and --flat_routing on combination only works with --router_lookahead map, which is the default option for VTR. Other router_lookahead options are not compatible with flat routing yet.
• This fix doesn't resolve issue Yoyo algorithm does not terminate #3727. The failures at 400ps uncertainty with FFT.v and MATMUL.v were due to the yoyo algorithm not terminating even when it reached 0 overused RR nodes.

Tests

I have included a new vtr_reg_strong task, strong_yoyo_flat_router. It has two circuits basic.blif and matmul.blif with corresponding SDCs. The circuits are constrained with uncertainties of 500ps and 300ps respectively. A VTR run with --routing_budgets_algorithm yoyo and --flat_routing on should result in 0 hTNS for both circuits.