[soft navs] Make PerformanceEntry.navigationId a number.

[chromium-wpt-export-bot]

https://w3c.github.io/performance-timeline/ specifies navigationId to be
a number, whereas Chromium currently implements it as a string. This
change fixes that. The "algorithm" for making a navigation id is
implemented in navigation_id_generator.cc, with commentary and unittest.
Updating the spec remains a todo after this lands.

Notes:

1. In largest_contentful_paint_calculator, there's a pre-existing
   "navigationId" in for the performance trace entries. I'm leaving this
   alone (slightly undoing the mixup there), but adding the performance
   timeline spec related ID as performanceTimelineNavigationId. The idea is
   that this will allow users of the trace to find corresponding
   PerformanceEntry instances e.g. from RUM data.

2. For the IDL file, the field is unsigned long long, just like it is in
   the spec. However, the C++ implementation uses uint32_t, because values
   above std::limits<int32_t>::max() don't make much sense for Javascript /
   JSON APIs.

3. I'll be preparing a Github PR to align the spec and this change
   Remove PerformanceEntry.id and rephrase id generation. w3c/performance-timeline#219; the PR needs more
   updating after this edit, so please consider that WIP for now.

Implementation Details:

The (simple) algorithm for randomly creating and incrementing navigation
ids is in navigation_id_generator{.h,.cc,_test.cc}.

It's a field of window_performance.{h,cc}, which is convenient in that
hard navigations that would reset the performance object will also
create a randomly initialized navigation id, whereas for soft
navigations (and bfcache restores if enabled), we'll trigger the small
increment. There's also a performance object that's not associated with
a local dom window, and this will dole out the default navigation id
value, which is 0.

One of the constructors for PerformanceEntry now delegates to the other one; and both have the navigation_id
parameter there, and then invoking that constructor by all subclasses,
passing in the navigation id. This is relatively simple and better than
getting it from the local dom window, because these things get
instantiated by a performance object / when there's a performance object
around, which now has the navigation id generator as a field.

I added a new test,
third_party/blink/web_tests/http/tests/inspector-protocol/tracing/performance-entry-navigation-id.js;
this exercises the navigation id for situations that we care about. We
actually don't care about situations with empty documents, because they
don't involve interesting performance entries.

To answer the question what happens with opening a window and then
reusing that for a document, I added two lines to
PerformanceLifetimeTest.SurviveContextSwitch in
window_performance_test.cc.

Bug: 421337393
Change-Id: Ia669a3f3eb201d491dafd49e488aa69558ecfd99
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6604387
Reviewed-by: Michal Mocny <mmocny@chromium.org>
Reviewed-by: Scott Haseley <shaseley@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1485889}

[wpt-pr-bot]

The review process for this patch is being conducted in the Chromium project.