RectAreaLight: cleanup and refactoring

[WestLangley]

Cleanup, removal of unused code, and some refactoring. There is no change to the algorithm or rendered output.

Some of the refactoring is subjective, obviously, but this is a first step of several in making sure our units are correct.

---

Regarding our implementation of area lights: Although the LTC algorithm we are using can be applied to other BRDFs, the corresponding ltcMag and ltcMat data is based on the GGX distribution specifically, and is not appropriate for Phong.

Just as Lambert does not support area lights, I would recommend we remove the Phong area light support, too. This will further simplify the codebase.

Users can use MeshStandardMaterial and MeshPhysicalMaterial, instead.

We hope to support other area light types -- and near and distant light probes -- too, I expect, and having to support two similar specular models doesn't make a lot of sense.

There have been suggestions to remove Phong completely, since it really is redundant at this point, but keeping it around as a simple specular illumination model, with Lambert as a simple non-specular model, is reasonable, I guess.

[bhouston]

The rect area light code-base is so huge, I would even split it into brdfs_area.glsl as it is taking over that brdf file and making it hard to find the other brdfs.

[bhouston]

Is the rect area light code even a BRDF? It is a little confusing as it seems to be mostly about light integration rather than surface evaluation. I would maybe try to split out the light evaluation (which is light eval code, and should go in lights.glsl) from the surface evaluation (which should go into brdf.glsl) if possible.

I think with the LTC area lights it is a little mixed up though, so maybe cleaning that up isn't possible.

[mrdoob]

Just as Lambert does not support area lights, I would recommend we remove the Phong area light support, too. This will further simplify the codebase.

Sounds good to me 👍

[mrdoob]

Thanks!