aoMap UVs are not transformed by texture matrix

[zeux]

Right now, the three.js texture sampling implementation works as follows:

• All textures use uv0 except for aoMap/lightMap that use uv1
• uv0 is transformed using the matrix from the first texture that uses uv0
• uv1 is not transformed at all

This creates a problem for the common workflows that include AO maps - it's more common to see meshes where AO UV data is exactly the same as that for other textures. In fact, glTF encourages this workflow by using G & B channels for metal/roughness and R for AO, and all examples from glTF-Sample-Models use the same channel (the only glTF model file I know of OTOH that uses a separate UV channel for AO daa is Littlest Tokyo).

The lack of texture transform is a problem for gltfpack, that relies on texture transforms for dequantization; AO UV data doesn't get transformed and as such gltfpack models with AO don't render properly in three.js (they render properly in Babylon.JS that implements per-texture transforms).

There might also be cases where procedural adjustment of AO UV data is necessary, although this is probably uncommon.

I know there are longer-term potential plans for full texture set / transform support in three.js, e.g. #12608, but they seem somewhat long term / unclear.

I'd like to fix this in the interim by introducing a second UV transform matrix with the same logic as the existing one - the values are going to be sourced from aoMap / lightMap, whichever is present, and used to transform UV data. There's no API change here, but I want to file the issue to make sure this seems reasonable.