explain: Add support for the new exec log format

[fmeum]

In Bazel 7.4.0 and Bazel 8, the compact execlog format has changed and now represents runfiles directories via a dedicated RunfilesTree method, which is both more space efficient and also allows attribution of changes to runfiles.

This change adds support for the new format and, to get the new tests to pass, also fixes a number of bugs:

• TransitivelyInvalidated no longer counts diamond reverse deps and spawns with multiple outputs twice.
• Source directories and tree artifacts are now diffed consistently, with the latter still being treated as an explanation for args changes.
• Track both a logical and a resolved path for inputs content diffs to make attribution of runfiles symlinks possible.
• Topological sorting did not visit all edges.
• Tool contents are no longer diffed separately as they are a subset of inputs.
• Bazel settings that make execlogs incomparable now result in an error.

[fmeum]

Apologies for the large diff, but implementing support for this feature without fixing the mentioned bugs was just too confusing for me.

[fmeum]

Bzlmod tests fail with

ERROR: While parsing option --startup_time=18446744073709550929: '18446744073709550929' is not a long

even on retries. Maybe something is off with the clock on that executor?

[bduffany]

@fmeum we've seen that error pop up from time to time but haven't yet figured out why it happens. It usually goes away with a re-run.

One thing that's suspicious is that 18446744073709550929 starts with a lot of the same digits as uint64_max. Since startup_time is a duration, it kind of seems like bazel is subtracting two timestamps that it's expecting to be monotonically increasing, but aren't, resulting in overflow. I vaguely suspect this could be related to VM snapshotting somehow (pausing/resuming the VM probably messes with the clock in some way?)