Use non-sticky BFCache blocking for WebLocks

This CL fixes an issue where pages using WebLocks were permanently
blocked from the BFCache.

Previously, WebLocks was registered as a sticky feature, which blocked
BFCache for the page's entire lifetime, even after the lock was
released. Now this CL ensures the block is only active while the lock is
held. This CL changes the behavior to register the blocking feature only
when a lock is granted and unregister it when the lock is released.

This CL also updates 2 tests and 3 test expectations:
- performance-navigation-timing-lock.https.tentative.window.js: Updated the test to hold the lock indefinitely, fixing a failure where the lock was released too early.
- SchedulingAffectingFeaturesTest.WebLocks: Removed since the feature no longer registers correctly in a renderer-only environment and its behavior is already covered by WPTs.

- abort.tentative.https-expected.txt
- release.tentative.https-expected.txt
- report-back-forward-cache-status-details-captured-expected.txt: Switching to a non-sticky feature registration causes the source location to be lost, so the details field is no longer reported.

Bug: 434557707
Change-Id: I102e936932e6b7b823fb53babf08e915953ca545
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6790586
Reviewed-by: Fergal Daly <fergal@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Anna Sato <annasato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1496135}