Pheww... Glad that I figured this out in time.

It happens on a project I'm working on, not sure still why. I guess this approach is safer.

Removed Vector* add() to addVectors() and addSelf() to add(). Same with sub, cross, min, max, lerp... Renamed Matrix* and Quaternion multiply() to multiplyMatrices(), multiplyQuaternions() and multiplySelf() to multiply(). See #2860.
Good thing we have a ton of examples to make sure nothing is broken. The unit tests also helped. However, I suspect I've left something unchanged.

Renamed .deallocate() to .dispose() as discussed in #2760 and fdb737d0.

Still unsure of whether to rename it to dispose instead.
I guess a problem of the world deallocate is that you're unsure wether it is dealocate or deallocate.

This will need some more thought, before we didn't really do anything about BufferGeometry deallocation.

Goes with #2657

Unfortunately we can't keep these settings always on: without "--jscomp_off=checkTypes" the amount of spam is just too crazy. It complains about tons of normal things, I had to manually dig out few useful warnings among 900 irrelevant ones.

See #2610

Big refactoring of BufferGeometry and CTMLoader: moved GL buffers initialization from loader into renderer, no more GL context dependency in loader.

BufferGeometry lifecycle now starts to resemble more regular Geometry one. Also this new architecture should make it easier to add more attributes.

Added dynamic updating of BufferGeometry. Added BufferGeometry.applyMatrix. Added Matrix4.multiplyVector3Array.

CTMLoader now keeps references to typed arrays used to initialize GL buffers. These are later on deleted in WebGLRenderer (by default, if BufferGeometry.dynamic flag is not set).

Fixes #2166

(this commit should go to `unflipped` branch, it assumes straightforward UVs)

Work in progress. For the moment works just with CTMLoader. Still not sure where some pieces of code would go.

Upsides:
	- initialization time cut down significantly (1.8 seconds => 0.7 seconds for CTM example)
	- much smaller GL buffers thanks to fully used indexing (Walt has 6x less vertices)
	- consequently much smaller memory footprint all around, both for main and GPU memories,
	  which means less swapping and better vertex caching

Downsides:
	- can't have anymore sharp per-face effects like flat shading (at least if mesh is not constructed in a way where each face has own vertices)
	- can't have multiple materials per mesh
	- no more easy manipulation of anything (for the moment actually no runtime manipulation at all, typed arrays are just thrown away, dynamic geometries code path not yet implemented)