[Performance Timeline] Final change to PerformanceEntry.navigationId

Hey folks,

When I presented two weeks ago at the WG call, I presented a number of
options for the navigationId field that we want to use to identify certain
performance timeline entries.

Presentation:
https://docs.google.com/presentation/d/10h4T_JGrBp5db_1owgqBFTCYyydmsEV7PD-l2YG4jjo/edit?usp=sharing
Issue:
https://github.com/w3c/performance-timeline/issues/182
Spec PR:
https://github.com/w3c/performance-timeline/pull/192

At the time, we discarded most of the options for different reasons:
 - counters quickly become relied upon by developers, despite any spec
warnings that they should not
 - UUIDs could be expensive to produce, and lose all ordering
 - objects don't have great equality semantics

I left the meeting with rough consensus that a string identifier, of the
form "{type}-{starttime}" would be easy to compute, easy to compare, well
ordered, and unique.

However, in talking with Yoav and Yash, who is heading up the Resource
Initiator project (which has similar requirements to link timeline entries
through some identifier), we realized that this id format wouldn't be
sufficient to uniquely identify resource timing entries, as the
starttimes could easily collide.

*However*, we realized that we already have the idea of a counter which
deters developers from relying on it, in the interactionId field in Event
Timing. That spec uses a coarsely-incrementing integer, which starts at a
random value, and increments by a small (but definitely >1) value each time
a new ID is required. I think that this would be sufficient for
navigationId, as well as for resource timing entries, and have reworked the
spec to use that instead.

I'd still love comments, either on this thread or in gitHub issues, if
there are ways to improve this; there are a couple of notes in the privacy
section now, about avoiding either fingerprinting or cross-window leaks,
but I think that this is sound, and I'm hoping it'll stick.

Ian