Change proposal for the fuzzy definition of a tick in `KHR_interactivity`

I am making my own glTF VR engine with multiuser and networking. I am very excited for the coming soon `KHR_interactivity` extension ! I have reread the extension today ([commit 048bc30](https://github.com/KhronosGroup/glTF/blob/048bc309bf5fb6340cd07157d9610350e17fb256/extensions/2.0/Khronos/KHR_interactivity/Specification.adoc)) with nice new bits in it but I found issues about the current concept of *tick* that I expose below with a proposed fix.

## Current definition of a tick

The extension specification refer three times to a tick :

> **4.1.4.1.4. Variable Interpolate**
> [...]
> On each tick, for each entry of the variable interpolation state dynamic array:
> 1. Compute the current input progress position t as the time passed since the interpolation start divided by the interpolation’s duration.

> **4.1.4.2.5. Pointer Interpolate**
> [...]
> On each tick, for each entry in the pointer interpolation state dynamic array:
> 1. Compute the current input progress position t as the time passed since the interpolation start divided by the interpolation’s duration.

> **4.1.5.1.2. On Tick**
> This node is activated when a tick occurs. There will be at most one tick per rendered frame, which SHOULD align with frame time, but there are no guarantees of time elapsed between ticks.
> [...]
> If multiple instances of this node exist in the graph, they MUST be activated sequentially in the order they appear in JSON and they MUST have the same output values within the same tick.

By reading the `On Tick` node definition, a tick is an event when all `On Tick` events are sequentially fired as if all `On Tick` nodes were merged and each `On Tick` subgraph is sequentially triggered exactly once. It is stated that at most one tick is generated per rendered frame and that is problematic in my opinion.

## Breaking that `There will be at most one tick per rendered frame`

A *rendered frame* without context can be interpreted as a *rendered video frame*. The extension would then be tied to a video game loop specific concept and applying this definition for my engine and use-case imply that :

* Since my editor start the engine in a separate process. If the editor video preview is disabled, the engine world logic must freeze until the video preview resume as no frame are rendered.
* A headless world server will never tick since it won't render any rendered video frame.

This is an absurd behavior but that conflates *rendered frame* and *rendered video frame*. Actually the glTF standard does not define what a rendered frame is. Which is a good thing because the standard should remains as neutral as possible and this is a fragile concept.

In the context of my engine, the `KHR_interactivity` part is hosted in the "reality module" which generates scene snapshots for other modules. These snapshot are the closest concept of *rendered frame* in the reality module and can come from a rendered video frame, audio frame, network frame and even a `KHR_interactivity` frame since it will need a scene snapshot for `pointer/get`.

Of course I can limit myself to trigger a tick for each video frame but if there are multiple video outputs then I want to avoid firing too many ticks per frame and if there are none I can imagine that many behavior graphs will break if not ticked for a long time and that will confuse users.

I believe that there has been an oversight on that seemingly non important sentence in the extension, glTF should refrain from using the concept of *rendered frame* as it seems obvious until you get into less common use-cases.

## Proposed change

It is unnatural to implement `KHR_interactivity` correctly in my engine and I believe in other engines too where pacing ticks with a timer makes more sense. I propose to let implementations do what they believe is the right thing.

Replace this paragraph :

> This node is activated when a tick occurs. There will be at most one tick per rendered frame, which SHOULD align with frame time, but there are no guarantees of time elapsed between ticks.

With this paragraph :

> This node is activated when a tick occurs. The implementation SHOULD produce ticks at a regular interval, but there are no guarantees of time elapsed between ticks.
> Implementation Note: ticks may be generated based on rendered frames or a periodic timer. The details of ticks generation are implementation-defined.

Read extensions/2.0/Khronos/KHR_interactivity/Specification.adoc, especially the Variable Interpolate, Pointer Interpolate, and On Tick sections, and compare them with commit 048bc30. Check the proposal against existing tick semantics and maintainer feedback; done means the specification’s tick wording is agreed on and updated consistently.

Written by the indexing model from the issue text.