[Spec] In-progress fenced frame navigation should be blocked if both navigated FF and initiator FF have network revoked

[xiaochen-z]

Fix #173.

The overall implementation is:

1. A flag is_embedder_initiated_fenced_frame_navigation_ is set during FF .config setter and passed down to the downstream navigation request.
2. OnResponseStarted(), if root is FF and the above flag is set then:
3. The in-progress embedder-initiated FF navigation should be blocked (see NavigationRequest::IsDisabledEmbedderInitiatedFencedFrameNavigation()) if both:
   • navigated FF has network revoked; and,
   • initiator FF has network revoked.

This PR specs the blocking of navigation in attempt to populate the history entry's document because in Chromium just a few lines below the call to NavigationRequest::IsDisabledEmbedderInitiatedFencedFrameNavigation(), there is CheckResponseAdherenceToCoep(), which is spec'd in attempt to populate the history entry's document's step 5 substep 4. So I think it is reasonable to spec them in the same place.

To check the navigation is an embedder-initiated fenced frame navigation, instead of adding a flag as it is implemented in Chromium, the following condition is checked, reused from the navigate algorithm patch.

fenced-frame/spec.bs

Lines 3550 to 3552 in cb57423

	1. If |navigable| is a [=fenced navigable container/fenced navigable=] and <var
	ignore>sourceDocument</var>'s [=node navigable=] is in |navigable|'s [=navigable/active
	document=]'s [=Document/ancestor navigables=] with [=an-unfenced|unfenced=] set to true:

---

Preview | Diff

[xiaochen-z]

• @VergeA to take a look, thanks.

[VergeA]

This LGTM % my one other comment.