Our implementation statefullness semantic differs from the specification. We should match the specification.

Current Behavior
----------------
- Animator class does not need to have a superclass
- Animators exist in a single global scope and are never removed. Making them effectively statefull. In another word this.property is always valid. 


Expected Behavior
-----------------
1. Introduce two new interfaces StatelessAnimator, StatefulAnimator. Update the registerAnimator to check for these super-classes (but probably not reject old plain class syntax).
2. StatelessAnimator instances should be required to be stateless [2]. To enforce this we can implement a global scope switching strategy similar to the one related to paint worklet that applies to these. [1]
3. StatefulAnimator instances should be required to serialize its state [3]. We have to come up with a way to enforce this. Perhaps periodically call animator.state() and recreate the instance using the serialized state.
(4). Once we implement above we should decide how to handle old syntax (classes with no super class). We can map these to be stateless, or reject them outright, or have them warn as deprecated and them after some time remove them.


The above list is ordered in what I hope is a reasonable way to tackle these tasks.


[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/csspaint/paint_worklet.cc?type=cs&sq=package:chromium&g=0&l=58
[2] https://drafts.css-houdini.org/css-animationworklet/#stateless-animator-desc
[3] https://drafts.css-houdini.org/css-animationworklet/#stateful-animator-desc