Documentation - Initial stubs, fixes, unification. Free lunch fer your beer.

- Pixi.js
  - Added basic YUIDoc entries to Pixi.js, including the addition of the
  "namespace-class".

- CanvasTinter
  - Removed constructor annotation from invalid double static/constructor pair
  - Added static annotations

- VideoTexture
  - Added initial documentation/stubs

- Updated all "scaleMode" params to link-to PIXI.scaleModes

- Fixed autoDetect* method documentation so they show up in the PIXI class documentation (as opposed to being reported as being classes themselves..)
I find the integer-type documentation annotations often better describes the range of acceptable values - in the given case that would indicate that a discreet value with a particular, but only described by the linked documentation, is probably required.

Even though it is not a "true" type in JavaScript I find that for documentation purposes the benefit outweighs the cost.

_However, I can understand that not everyone has my viewpoint and not every project allows this convention - so I'll change (all) the {Integer} back to {Number} if that is The Way this is to be done for pixi._ (I'm not bothered by such Integer change being rejected, that's just part of learning the :dancer: for the :tada: )

Alternatively, I could
- Change it to `@param {PIXI.scaleModes}` or
- Add an Integer type (which would explain that it was a number of which the only valid values were integers) so everything is linked up :grin: