Faster log parsing: fix parse_vtr_flow.py to only read each log file once

[jgoeders]

Description

Related Issue

Closes #1647

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[vaughnbetz]

The failures in vtr_reg_nightly are due to QoR improving on a few circuits:
arm_core has significantly fewer RAMs, which is making area/resource count QoR too good to pass. @sdamghan : I think your recent changes improved memory QoR: was arm_core a big win? If so we need new golden results?
That's 16 faiures.
The last one is in Titan, and is a worst-negative slack that got a lot better. Jeff can you double check that wns was parsed correctly? If so we can merge this.
stratixiv_arch.timing.xml/minres_stratixiv_arch_timing.blif/common setup_WNS relative value 1.4499921074291642 outside of range [0.5,1.4] and not equal to golden value: -7.09528

[jgoeders]

@vaughnbetz

When I run stratixiv_arch.timing.xml/minres_stratixiv_arch_timing.blif locally on this branch I'm seeing Final setup Worst Negative Slack (sWNS): -8.91171 ns in the log, which is also what the parser is extracting, and within the QoR range.

If I understand how the golden works, the relative value the nightly found (1.4499921074291642) and golden (-7.09528), would mean a WNS of -10.288, which seems like a large increase, and not matching what I found locally.

It's running again now, but I'll investigate some more.

[jgoeders]

I ran the full vtr_reg_nightly locally and indeed I get:
Final setup Worst Negative Slack (sWNS): -10.2881 ns

So it is parsing it correctly.

I'm not sure why I got different results when trying to run the individual design on it's own, although I seemed to have missed the --initial_pres_fac 1.0 --router_profiler_astar_fac 1.5 configuration that this circuit is run with in the regression test so that's probably the reason.

[jgoeders]

@vaughnbetz , since it seems like the parsing is working fine, I'm going to merge this.