pointerLock vendor prefixes, shims and usability

The pointerlock API is currently prefixed with vendor prefixes. This is
fine in principle since it is an experimental API that lacks consistency
and consensus and that's what vendor prefixes are for.

A vendor prefix should serve to inform a developer that he's using
non-standard functionality that may break or change, I get it, that's fine.

It is however inconvenient to write out moz/o/msie/webkit/etc. everywhere
in your code. Shims are one solution to this issue which enjoys some
popularity (other people call it polyfill).

You cannot write a shim/polyfill for pointerlock for the following reasons:

- vendorRequestPointerLock is on the prototype to HTMLElement which you
cannot modify in Firefox
- vendorMovementX etc. are set by the event construction to mousemove, one
cannot override and wrap the HTMLElement prototypes addEventListener. Even
if one could, one would not want to allocate an object for every event in
JS userspace (GCing being hurtful to realtime applications)
- vendorpointerlockchange events can likewise only be abstracted by
overriding HTMLElement's prototype which is a nogo.
- document.mozPointerLockElement cannot be shimmed at all obviously (you
cannot listen to document property changes)

Is it really necessary to attach those prefixes everywhere and pollute our
code with them? It makes it positively painful to write, maintain and move
forward with the code. Perhaps that is the intention, I don't know, but I
don't approve.

Please for the love of not making web developers suffer, do come up with an
alternative to this madness. It was already bad when it was done in CSS,
but in JS it gets really really bad.

Thank you.