Rewrite the Automation section and redefine the spec's extension comm…

…ands (#470)

The previous version from #369 and #377 was never implemented by any
engines, and the language it used made it hard to actually implement and use
in tests (such as those already present in web-platform-tests). For example:
- Mock sensors acted like a mix of device sensors and platform sensors, and
  the distinction was not entirely clear.
- Mock sensors had a separate readings map that never really integrated with
  the "latest reading" concept used in the abstract operations.
- The language in the "Create mock sensor" extension command did not make it
  clear if it was attempting to create Sensor objects or hand-wavingly
  change existing Sensor objects' associated platform sensor.
- Implementing the custom WebDriver error codes specified here was not
  trivial and did not bring much extra benefit (other specifications refrain
  from doing it as well).
- Calling "convert to an IDL value" to convert JSON Objects to a platform
  version is not always trivial to implement since it actually requires a
  lot of extra WebIDL processing steps that are not really needed here.

The new version uses more precise language in the algorithms and properly
integrates into the existing abstract operations. It has also been verified
to work with Chromium, ChromeDriver and the required changes to
web-platform-tests.

"Mock sensors" are now called "virtual sensors" to follow the same
terminology adopted by the WebAuthn spec.

Conceptually, they are now defined as device sensors and therefore always
exist at a layer below a platform sensor. This clears up ambiguities and
delimits what is expected of platform sensors and what can actually be
influenced by a virtual sensor.

Some auxiliary concepts also had to be defined, both of which are expected
to be set by extension specifications:
- "Virtual sensor metadata" is a struct with a sensor type and an algorithm
  to parse the readings sent to the "update virtual sensor reading"
  extension command.
- "Per-type virtual sensor metadata" is a mapping of strings to virtual
  sensor metadata instances. This allows us to get rid of MockSensorType, as
  the keys are then used to identify a given sensor type in the WebDriver
  extension commands and each specification defines one or more keys.

The same virtual sensors are used by all navigables that have the same
top-level traversable. In other words, all iframes under the same main
frame, regardless of their origin, share the same virtual sensors. Not only
does this match the behavior of real, hardware-based sensors more closely,
but it also helps with a limitation in web-platform-tests' testdriver.js
that only allows WebDriver communication to go through the page that creates
the test harness.

Co-authored-by: Reilly Grant <[email protected]>