Improve FrameTreeNode tracking in URLLoaderNetworkContext

In the current code, URLLoaderNetworkContext in StoragePartitionImpl
is created for a document, service worker, or a navigation. For a
document, it's tracking with RenderFrameHostImpl and, for navigation,
it's tracking with a FrameTreeNode ID.
It has three different incompatible uses of Routing ID for navigation
request, a frame, or service worker.
Here, we're also using the FrameTreeNode id as a proxy, but it's not
ideal as the navigation can be canceled and another navigation can
start in the same FrameTreeNode.

This CL introduces NavigationOrDocumentHandle that has a weak ptr
to RenderFrameHostImpl or NavigationRequest and
URLLoaderNetworkContext is created with it.

It includes several changes,
- it introduces NavigationOrDocumentHandle to support a seamless
transfer from a navigation to a committed document. It has
RenderFrameHost or NavigationRequest for the network context.
If the context is created for a navigation request, its
RenderFrameHost member is populated when the navigation is
committed.
- it incorporates two CancelIfPrerendering() helpers, one with
`frame_tree_node_id` and the other with `render_frame_host_id`,
by taking NavigationOrDocumentHandle.
- RenderFrameHost and NavigationRequest create
NavigationOrDocumentHandle and URLLoaderNetworkContext refers to
them when they are created.

This is a follow-up CL of https://crrev.com/c/3261291

Bug: 1241836, 1239554
Change-Id: I2c6abe17436c276c460e1721fc8b1ef2b38a5ae0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3341866
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Julie Jeongeun Kim <jkim@igalia.com>
Cr-Commit-Position: refs/heads/main@{#988227}