Define and implement ProcessSelectionDeferringCondition API

This CL adds a ProcessSelectionDeferringCondition and
ProcessSelectionDeferringConditionRunner which is modeled after the
existing CommitDeferringCondition API but is invoked at an earlier stage
of the navigation lifecycle. The feature is guarded by a feature flag,
kProcessSelectionDeferringConditions, which is disabled by default. The
first client of this API,
`site_protection::SiteFamiliarityProcessSelectionDeferringCondition`,
is implemented in a subsequent CL ( crrev.com/c/6897186 ).

This makes it possible for some features to toggle their state based on
whether a site is familiar to the user's profile. The services we want
to use in determining site familiarity involve using asynchronous APIs
that introduce delays due to thread switching. To enable these calls,
we're adding a ProcessSelectionDeferringCondition API that allows
clients to be notified at navigation start, on redirect, and before the
process selection is finalized.

The standard ways of observing the navigation flow (WebContentsObserver
and NavigationThrottle) do not work for this use-case because the
settings we need to toggle have to be determined before the renderer
process selection is finalized. Both WebContentsObserver and
NavigationThrottle provide WillProcessResponse() but this handler is
called after the process selection has been finalized. The existing
CommitDeferringCondition mechanism does not work for the same reason --
it also defers after the final process selection is made.

Overview of how the ProcessSelectionDeferringCondition works:

1. A client implements the ProcessSelectionDeferringCondition
   interface and registers in the appropriate embedder by overriding:
   ContentBrowserClient::CreateProcessSelectionDeferringConditionsForNavigation().

2. When a navigation begins, it creates a
   ProcessSelectionDeferringConditionRunner and registers any
   ProcessSelectionDeferringConditions that are provided by the
   ContentClientBrowser. A NavigationHandle is passed into the
   constructor at this time so that deferring conditions may begin work
   on the navigation as soon as they are created.

3. If the navigation is redirected,
   ProcessSelectionDeferringCondition::OnRequestRedirected() is called
   to allow conditions to reset or restart their work.

4. After the network response is received but before a process is
   selected, ProcessSelectionDeferringCondition::OnWillSelectFinalProcess()
   is called. The condition can then:
   * Return Result::kProceed to allow process selection to continue
     synchronously.
   * Return Result::kDefer to pause process selection. The condition
     must then invoke a provided resume closure to resume the
     navigation.

Overview of changes:
   * Define the ProcessSelectionDeferringCondition interface in
     content/public/browser.
   * Implemented ProcessSelectionDeferringConditionRunner to manage the
     running the registered conditions.
   * Integrate the runner into NavigationRequest, calling it at
     redirects and before the final call to
     SelectFrameHostForOnResponseStarted.
   * Add the CreateProcessSelectionDeferringConditionsForNavigation
     API to ContentBrowserClient for embedders to register their
     ProcessSelectionDeferringConditions.
   * Added browser tests and unit tests for the new mechanism.

Change-Id: I5888202e8433c4eb405c2bb85d4e60d4872396ec
Bug: 434009835
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6784549
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Peter Kotwicz <pkotwicz@chromium.org>
Commit-Queue: Javier Castro <jacastro@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1520795}