whatwg/webidl#859 removed the "present" and "not present" terms; specs are
supposed to use Infra's "exists" for dictionaries instead.

We had already done this in w3c#440, but there were some leftovers in the
Automation section.

Related to w3c#444.

This fixes Bikeshed warnings like

    LINT: Unexported dfn that's not referenced locally - did you mean to export it?
    <dfn bs-line-number="550" data-lt="reading value" data-dfn-type="dfn" id="reading-value" data-noexport="by-default">values<a href="#reading-value" class="self-link"></a></dfn>
    <dfn bs-line-number="550" data-lt="reading value" data-dfn-type="dfn" id="reading-value" data-noexport="by-default">values<a href="#reading-value" class="self-link"></a></dfn>

Some definitions used to be referenced years ago in previous versions of the
spec text.

While here, also fix

    The var 'latest reading' (in algorithm 'update latest reading') is only used once.
    If this is not a typo, please add an ignore='' attribute to the <var>.

by referencing the dfn rather than using `latest reading` as a variable.

Related to #444.

This fixes Bikeshed warnings like

    LINT: Unexported dfn that's not referenced locally - did you mean to export it?
    <dfn bs-line-number="550" data-lt="reading value" data-dfn-type="dfn" id="reading-value" data-noexport="by-default">values<a href="#reading-value" class="self-link"></a></dfn>
    <dfn bs-line-number="550" data-lt="reading value" data-dfn-type="dfn" id="reading-value" data-noexport="by-default">values<a href="#reading-value" class="self-link"></a></dfn>

Some definitions used to be referenced years ago in previous versions of the
spec text.

While here, also fix

    The var 'latest reading' (in algorithm 'update latest reading') is only used once.
    If this is not a typo, please add an ignore='' attribute to the <var>.

by referencing the dfn rather than using `latest reading` as a variable.

Related to #444.

The original note was added in #267 and expanded in #347, but its advice is
impractical:
- Sharing the activated sensors objects between multiple browsing
  contexts/documents/windows means these Sensor objects could potentially be
  shared by contexts in different top-level traversables (i.e. different
  tabs).
  Furthermore, if "can expose sensor readings" passes for one context but
  not the other, "update sensor reading" would still invoke "report latest
  reading updated" with sensors that cannot expose sensor readings.
- Similarly, if the latest reading map is shared between multiple contexts,
  an update would affect all contexts, including those for which "update
  sensor reading" should not have been invoked in the first place (e.g. two
  pages with the same origin share the latest readings map, but only one is
  visible; updates to the latest reading map would be accessible from the
  other as well).

PR #267 also made the "platform sensor" concept used in this section
per-browsing context (although in a very confusing way), which on its own is
a stricter requirement than what the note allowed, so we can drop the note
without making things less secure.

Incidentally, this also gets rid of one of the usages of "browsing context"
in the spec, which helps with #444.

Add an algorithm that operates on specific concepts such as navigables, and
use the "origin" definition from an environment settings object, which,
according to the HTML spec, is "an origin used in security checks".

Related to: #444 (gets rid of some "browsing context" references)
Related to: #463

The original note was added in #267 and expanded in #347, but its advice is
impractical:
- Sharing the activated sensors objects between multiple browsing
  contexts/documents/windows means these Sensor objects could potentially be
  shared by contexts in different top-level traversables (i.e. different
  tabs).
  Furthermore, if "can expose sensor readings" passes for one context but
  not the other, "update sensor reading" would still invoke "report latest
  reading updated" with sensors that cannot expose sensor readings.
- Similarly, if the latest reading map is shared between multiple contexts,
  an update would affect all contexts, including those for which "update
  sensor reading" should not have been invoked in the first place (e.g. two
  pages with the same origin share the latest readings map, but only one is
  visible; updates to the latest reading map would be accessible from the
  other as well).

PR #267 also made the "platform sensor" concept used in this section
per-browsing context (although in a very confusing way), which on its own is
a stricter requirement than what the note allowed, so we can drop the note
without making things less secure.

Incidentally, this also gets rid of one of the usages of "browsing context"
in the spec, which helps with #444.

Add an algorithm that operates on specific concepts such as navigables, and
use the "origin" definition from an environment settings object, which,
according to the HTML spec, is "an origin used in security checks".

Related to: #444 (gets rid of some "browsing context" references)
Related to: #463

As described in #478, the current behavior is underspecified and allows
implementations to discard readings provided to the "Update virtual sensor
reading" WebDriver endpoint when no sensors are currently registered to
receive readings.

This makes writing some tests (especially Device Orientation API ones)
harder, as one then needs to order calls in a very specific way so that a
virtual sensor is created, a sensor is activated, a virtual sensor reading
is provided and then it is consumed by a sensor. To complicate things
further, implementations may differ in when they deactivate sensors (think
page visibility handling, for example).

It is easier to mandate one specific behavior:
* Readings are never discarded. They are always saved and are stored as long
  as the virtual sensor exists
* If there are active sensors when they are received, they are also made
  available to said active sensors.
* Whenever a sensor connects to a virtual sensor and wants to start
  receiving readings, the virtual sensor will provide its saved reading to
  it if there is one.

In practice, this means one can call `test_driver.update_virtual_sensor()`
before a Sensor object is even created (or a Device Orientation event
listener is added), or that if one calls Sensor.stop() followed by
Sensor.start() the previous reading will be reported again.

Making this possible requires several changes across the specification
though, as virtual sensors need to keep track of platform sensors but
platform sensors did not have their lifetime properly defined. Furthermore,
the virtual sensor changes need to be flexible enough to be possible to use
them in the Device Orientation specification, which has no concept of
platform sensors or sensor types at all.

Platform sensors:
- Platform sensors are now Document-bound. Their definition in the
  "Concepts" section remains more abstract, but when used in algorithms and
  interacting with platform objects, they are always treated as belonging to
  a Document.
  This change also removes all usages of "browsing context" and finally
  gets rid of all Bikeshed warnings.
- Platform sensors are kept in a per-Document `[[sensorMapping]]` internal
  slot, a map of sensor types to platform sensors. This helps with the
  above, and also helps define that there is at most one platform sensor per
  sensor type in a Document, which is shared by Sensor instances with the
  same associated sensor type.

Virtual sensors:
- The concept of "platform sensor-like" was added to account for the Device
  Orientation API. It is like a platform sensor, but without the Generic
  Sensor-specific parts that are not used in the Automation section (sensor
  type, latest reading map, activated sensor objects).
- Virtual sensors now have two more associated items: a set of platform
  sensor-likes (which are notified when there is a reading), and a latest
  saved reading map (self-explanatory).
- When "update virtual sensor reading" is called, the stored reading now
  contains a "timestamp" key, so that if a reading is sent more than once it
  contains the same timestamp.

The interaction between per-document platform sensors and per-top-level
traversable virtual sensors works as follows:
- When a virtual sensor exists, a platform sensor adds itself to the
  former's set of connected platform sensor-likes and also sets it as its
  associated device sensor.
- When "set sensor settings" is called with an empty active sensor objects
  set, the platform sensor removes itself from its virtual sensor's set of
  connected platform sensor-likes. When the active sensor objects set is not
  empty, it checks if it is being activated (i.e. the previous sampling
  frequency was 0) and, if so, it retrieves the virtual sensor's latest
  saved reading.
- When a Document is unloaded, all platform sensors in `[[sensorMapping]]`
  are removed from their virtual sensors' connected paltform sensor-likes
  set.
- When a virtual sensor is removed, any connected platform sensor-likes have
  their associated device sensor set to null.

Fixes #444 (removes all remaining browsing context references).
Related to #478.