Avoid throwing out_of_range in log_fmax when related clocks lack Fmax entries

[bengtsjolen]

When two "related clocks" have no entries in result.clock_fmax, log_fmax() wrongly assumes that both have entries and
calls clock_fmax.at() for both and then throws std::out_of_range.

This patch:

• explicitly checks the has_a && has_b and else-case is then !has_a && !has_b case
• skips the "both missing" case and logs a warning instead

This fixes a crash I hit on ECP5 when a reset-like net and a derived FF clock
were treated as related clocks but had no computed Fmax.