Rewrite the Automation section and redefine the spec's extension commands

[rakuco]

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.

---

Preview | Diff

[rakuco]

@reillyeon the cleanup pull requests I've been sending have also helped pave the way for this one, as I needed some clear concepts I could hook into for this to work.

Overall, there was a change in terminology (s/mock/virtual/) and the virtual sensors are treated like device sensors. The rest is of the PR contains more precise algorithms for the extension commands + changes to the main operations so that they integrate with virtual sensors.

[rakuco]

@reillyeon I was wondering if you've had time to take a look at this one? I was hoping to land this PR before TPAC to send the corresponding web-platform-tests changes and ask reviewers to look at them during TPAC if necessary.

[rakuco]

@reillyeon friendly ping

[rakuco]

Thank you!