Fix platform collector cardinality, define pressure source and activa…

…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.