Overhaul frequency management in the specification

[rakuco]

This commit addresses a few issues with the way frequency management was
handled in the specification:

1. "Sampling frequency" was interchangeably used as a number as well as an
   interval ("sampling frequency bounds"), and the latter was not even
   properly defined.
2. The actual bounds were not properly defined, and neither was the clamping
   process that used them.
3. There were too many frequency-related terms in use.

Let us start with the changes in the concepts and definitions:

• A platform sensor has a sampling frequency, a positive number or null.
  It represents the frequency at which the platform sensor attempts to
  retrieve data from the device sensor and it is calculated in an
  implementation-defined manner based on the [[frequency]] of the
  associated Sensor objects. It is therefore a mixture of the previous
  "sampling frequency" and "requested sampling frequency" definitions.
  • How the sampling process works is implementation-defined: it could be
    polling, or requesting updates at this interval, or something else
    entirely.
• A device sensor has a sampling frequency. It is similar to the above, but
  operating system or hardware dependent and opaque to this specification.
  • As such, the device sensor may choose a sampling frequency that differs
    from the platform sensor's sampling frequency and we have no control
    over it.
• A device sensor MAY report lower and/or upper sampling frequency bounds.

With the above, the actual sampling bounds are defined and checked:

• A sensor type MUST have lower and upper sampling frequency bounds. The
  lower bound is "max(implementation-defined value, optional spec-defined
  value)", and the upper bound is "min(implementation-defined value,
  optional spec-defined value)".
• A new algorithm returns a platform sensor's lower and upper sampling
  bounds as a tuple "(max(optional device sensor lower bound, sensor type
  lower bound), min(optional device sensor upper bound, sensor type upper
  bound))".
• A Sensor's [[frequency]] is always set to a value within a platform
  sensor's sampling bounds in "Connect to a sensor" (before that it might
  not have an associated platform sensor and should be in the "activated"
  state).
• "Set sensor settings" requires that the platform sensor sampling value
  calculated based on its associated sensors' [[frequency]] values lies
  within its sampling bounds.

The "optimal sampling frequency" and "requested sampling frequency" s
have been removed, and so has the "Find the reporting frequency of a sensor
object" algorithm, which addresses point (3).

The "Automation" section has only received enough changes to avoid Bikeshed
errors and warnings, as the entire section is being rewritten.

Related to #463.

---

Preview | Diff

[reillyeon]

LGTM with nits