- there is one platform collector per global object (GO)
- a platform collector will use virtual sources for non-worker GOs
- virtual sources update data at a given sample rate set when created
- pressure observers collect data at their own given sample rate

It was not being used anywhere; the source type is always when manipulating
the virtual pressure source mapping, which uses source types as keys.

This makes it more clear when writing the spec that this is a concept
related to a virtual pressure source rather than a general one.

…te algorithm

This makes it possible to invoke it from multiple locations in preparation
for supporting adding a virtual pressure source that reports itself as
non-existent.

While here: add `class="algorithm"` to the "data collection" algorithm.

This flag can be set in the "create virtual pressure source" endpoint, where
it is set to true by default.

When false, it causes calls to PressureObserver.observe() to reject with
NotSupportedError when attempting to use the given virtual pressure source.

Merely for readability; if we reach the assertion, it means there must
be exactly one element in the owning set (only shared workers would
have more than one owning document).

- Get rid of `|data|` altogether. Specifying a return variable in the
  algorithm declaration is at the very least unusual. Furthermore, `|data|`
  and `|state|` were serving the same purpose in the virtual pressure source
  case while not working correctly in the non-virtual one at all: in the
  non-virtual case, `|data|` would always be null and the entire algorithm
  would abort. Furthermore, even if it did not, the subsequent step was
  reading `|data|` without ever writing to it first.

- Stop setting a virtual platform sensor's "pending sample" to null after
  reading it. It is not necessary; if the same sample is sent on a later
  call, the other algorithms (like "has change in data") should take care of
  ignoring it instead.

- Formatting: add missing `<p></p>` tags to the `<aside>` block.

…tion/deactivation

This addresses
w3c#265 (comment) by
properly defining several concepts in one change:

- "Pressure source" is now a proper `<dfn>`. It is similar to a "device
  sensor" in the Generic Sensor API spec, in that it works as the concept
  closest to the OS/hardware and retrieves some abstract telemetry data that
  is fed to one or more platform collectors. A virtual pressure source is a
  pressure source.

- Platform collector's granularity has been fixed: there isn't one per
  global, but rather one per source type. To make it easier to follow, a
  global now has a "platform collector mapping" rather than just an
  associated platform collector.

- Each platform collector now has some associated data: an "associated
  pressure source", which is the pressure source it retrieves data from, as
  well as an "activated" flag that is used when activating/deactivating data
  collection.

With these new building blocks, we can fix and/or properly define some
concepts that have been unclear so far:

- A null associated pressure source indicates that a given pressure source
  is not available.
  This is used, for example, in `PressureObserver.observe()`, which is now
  responsible for creating a platform collector when one is not available in
  its global and attempting to set the platform collector's associated
  pressure source to either a virtual pressure source or a real one.
  When neither can be found, it remains null, which signals that `observe()`
  must reject with NotSupportedError.
  Previously (see w3c#273), the `observe()` steps simply checked if `|source|`
  was a "valid source type", which did not properly reflect the potentially
  asynchronous checks involved in the real pressure source case.

- The absence of an entry for a given source type in the "platform collector
  mapping" indicates that `PressureObserver.observe()` must attempt to
  create a new platform collector as described above.
  An existing "platform collector mapping" entry is removed only by calls to
  `disconnect()` and `unobserve()` as well as when a document is no longer
  fully active or a worker's closing flag is set to true.
  Conceptually, this indicates more clearly that once a platform collector
  is created in `observe()` it will continue using the same associated
  pressure source. In other words, if `observe()` is called before "create
  virtual pressure source", all observers for the same source type will
  continue using a real pressure source until they all disconnect (and
  vice-versa).

- A virtual pressure source keeps track of connected platform collectors so
  that it can set their associated pressure source to null when it is
  removed before they disconnect. This is used in the new data collection
  algorithm described below.

- The data collection steps have been revamped.
  - "Data collection" itself has not changed much: it tries to get a
    platform collector's pressure source if one exists, read data from it
    and dispatch it to observers.
  - We finally have proper definitions for what it means to activate and
    deactivate data collection. The steps themselves do not do much besides
    making sure 1) a platform collector for the desired source exists and 2)
    these steps cannot run more than once for a platform collector. The
    "deactivate data collection" steps also takes care of removing a
    collector from a virtual pressure source's connected platform collectors
    set.

…ation-defined

As suggested by @kenchris.

This reverts commit 19e894e ("data
collection: Say adjusted pressure state calculation is
implementation-defined").

"Adjusted pressure state"'s definition already says the algorithm is
implementation-defined.

While at it, also make the paragraph that says platform collectors
should be able to connect to virtual pressure sources easier to
understand: stop talking about adjusted pressure sources and just say
"pressure sources", which is what the "adjusted pressure source"
algorithm outputs.

…ases

With platform collectors now being per-global and per-source type, we need a
way to clearly indicate that the "unprocessed" timestamp from a sample (i.e.
what is fed to "relative high resolution time") must be the same across all
globals.

We also need to make sure that this works for both real and virtual pressure
sources.

- The abstract "pressure source" concept added a few commits ago now has an
  accompanying "pressure source sample" concept. It is a struct holding
  implementation-defined telemetry data as well as a timestamp corresponding
  to when it was obtained.
  Functionally, this should be identical to the what the spec has as of pull
  request w3c#280.

- Virtual pressure source's "pending samples" is now a struct as well,
  holding similar data: a PressureState (like before) and a timestamp that
  is set to the "unshared current time" when the "update virtual pressure
  source" endpoint is called.

- The "data collection" algorithm is responsible for reading either a
  "pressure source sample" or a virtual pressure source's "pending sample"
  and processing the timestamp value as necessary.

They were basically the same: a struct with data and a timestamp. In the
"pending sample descriptor" case, the data was always a PressureState,
whereas in the former's case it was an implementation-defined value.

Since a virtual pressure source is a pressure source, we can say it also has
an associated pressure source sample instance, so we can just use it and
always set its data to a PressureState.

This was copied from the Generic Sensor spec and not done in other places,
so drop the tag for uniformity.

… types"

This ensures that the types accepted in automation are the same which are
returned by `PressureObserver.knownSources`.

Whether this is really desired can be worked out later.

…rmation"

…essure sources

…pping

Avoid adding a platform collector with an empty associated pressure source
to the platform collector mapping.

Having observe() attempt to find a suitable platform collector every time in
this case is not that expensive, and _not_ doing it leads to a situation
where inactive observers still need to call unobserve() or disconnect() to
remove an entry from the platform collector mapping (to get observe() to try
to connect to a platform collector again, for example).

Usage so far had been inconsistent, with some places using the `!`
syntax for normative references and others not doing so.