Multiple POI_List matches on Same Frame can be Ignored

[roninpawn]

While analyzing speedy_boy's Medieval Any% run (1:38.750), SplitRP does not find the correct start-of-run frame.

Looking into the POI_List shows that two matches are made on Frame 1:

1 {'LS Dark': [82.96687400549689, 7, 0.0], 'LS Light': [94.43801533342977, 46, 0.0]}
6 None
7 None
8 {'LS Dark': [82.69202950961956, 46, 0.0]}
45 None
46 None

LS Dark is found, and it drops its match on Frame 7, which is detected again on Frame 8 and continues until frame 46. But LS Light is also found, with a much better match percent, continuing unbroken until frame 46.

The desired behavior is that the Level Select screen is counted as persisting until frame 46 where all matches cease. But instead, because LS Dark is first in the list, LS Dark is used exclusively and LS Light is never considered. So timing ends up reporting that the Level Select screen drops on frame 7, and uses that as the start of the run.

There's already a system in place meant to handle this in UnMatch testing. It's meant to check and see if there's an open test (like LS Light here) that bridges any gap in the current Test Pack. But it doesn't work in this instance for some reason. I suspect that the UnMatch test simply wasn't written to recursively find ANY valid test in the relevant test pack, instead just looking for other open Tests of the same name. I'll find out when I look deeper.

But this bug / oversight encourages me to re-write the whole _map_splits() function for a third time. The POI_List itself is brilliant. Meanwhile, this logic to interpret the list still feels shoddy.

[roninpawn]

The UnMatch testing mentioned above was focused entirely on finding open_events that would trigger the UnMatch cycle. It simply had no consideration for preserving the match if an open_event affirmed it should still be held open.

I still think the _map_splits() could be rewritten, but I've patched out this bug with the 4 or 5 lines of code needed.
I'll close the issue with the next push. (and probably a bug-patching release)