Need to test this on IE9... :)_

Maybe `Geometry::computeNormals` should be renamed to `Geometry::computeFaceNormals`?

As suspected, this was caused by incorrect shader state management when switching between multiple shaders (thanks Firefox for verbose warnings).

Also, testing WebGL performance is very tricky. You can get different performance depending on the state of browsers / system (messed up state can be 10-66% slower):

1. freshly started Chrome can be much faster than Chrome that already ran few WebGL demos (which are now closed)
2. demo opened in new Chrome tab can be faster than demo reloaded in the same tab
3. even demos opened and closed in Firefox can slow down Chrome demos

This suggests that browsers do not clean GPU state properly :(

Added irc channel info in README.

Now that WebGLRenderer does VBO per geometry I guess we don't need that GeometryUtils.merge there. Makes loading much faster too.
Fresnel demo has a weird artifact now... As if the cubemap was smaller than the far of the camera?

Matrix4.transformVector4 ⟶ Matrix4.multiplyVector4

The most tangible practical effect is that demos with multiple Lucys / Walts are now initialized much faster ;).

Reuse is achieved mostly by moving mesh chunks / VBOs (formerly called materialFaceGroups) from Mesh into Geometry.

This means sorting of geometry by face materials + breaking large geometries into chunks now has to be done after construction of geometry.

It becomes a step in the usual sequence:

    geometry.computeNormals();
    geometry.computeCentroids();
    geometry.sortFacesByMaterial();

If geometry is constructed programmatically (e.g. with GeometryUtils.merge), this has to be called afterwards.

Also of note: single geometry cannot be reused both for flat and smooth shading, as only one stream of normals is baked into VBO.

TODO: Add computeVertexNormals on geometry so any object can use it.

Because CanvasRenderer now checks if `map.loaded == true` (following WebGLRenderer behaviour) some examples got broken.

Implemented gero3's Matrix4.transformVector3 optimisation ( http://jsperf.com/diff-in-speed-for-three-js ).

Somehow they got forgotten in the merge when "THREE.RefractionMap" got renamed to "THREE.RefractionMapping".