Fix for issue 9439 report_checks crash

[openroad-ci]

Fix for The-OpenROAD-Project/OpenROAD#9439
This is a specific type of crash that can be reproduced with a small set of commands.
When we do report_checks with any valid "-path_group" flag other than default, it is expected to show that particular path group.

But if a default path group has been created explicitly in the design with group_path -from -to -default, then the above call of report_checks causes a crash.

This happens because of a NULL dereferencing in the visitPathEnd function that triggers from report_checks command.

Firstly, from PathGroups::makeGroups, path_delay_[mm_index] is initialized to NULL when report_checks is executed.
This is because reportGroup(path_delay_grp_name_,group_names) is false as "group_names" is whatever was provided with the "-path_group" flag in report_checks command, and path_delay_grp_name_ is a string that is just "path delay" corresponding to the default path group (note that crash happens in report_checks for non default path group)

Now code path from sta::Sta::findPathEnds --> sta::Search::findPathEnds -->sta::PathGroups::makeGroupPathEnds --> sta::MakePathEnds1::visit iterates over all path groups. This happens as visitPathEnd visitor iterates over path_groups via path_groups_->pathGroups(path_ends).

There are many path groups in the design, but for the default path group, it shouldn't be trying to use path_delay_[mm_index] object as it was initialized to NULL. Without a NULL check in PathGroups::pathGroups function, this NULL pointer will get pushed into the path_groups variable that is returned in the iterator. Then when we call visitPathEnd(path_end,NULL), there is a direct NULL dereferencing causing the crash from there.

So crashing stacktrace shows from visitPathEnd, but the problem had happened in a couple of above stacktrace that is now fixed. A testcase is added to catch the issue