Use a persistent lockfile to speed up reproducible extensions

[fmeum]

Reproducible extensions are not included in the regular lockfile in order to keep it small and less prone to merge conflicts. But reproducible extensions can still take significant time to evaluate, which currently happens on every server restart.

This commit makes it so that Bazel maintains an additional lockfile, stored under the output base and not visible to the user. It only records information that remain correct indefinitely, such as the results of reproducible extensions as well as hashes of module files from registries. See the comments on BazelLockFileValue for a detailed comparison of the contents of the two lockfiles.

Fixes #24723

[fmeum]

Notes for the review:

• Stacked on Fix edge cases in lockfile handling #24754
• I haven't added any new tests yet. I will do so after we have reached consensus on the implementation.
• The failing test cases are caused by Skyframe node invalidation after the first bazel command in each test due to the creation of the new lockfile. This affects commands that operate on Skyframe state directly. These commands are inherently brittle, so I lean towards the simple workaround of adding an additional bazel build //... --nobuild invocation to the relevant tests instead of e.g. generating a default persistent lockfile for tests.