SL-19564 Rebalance exposure and sky.  Hack legacy diffuse map saturation and brightness to allow ACES Hill all the time.

* SL-19538 Remove hacky ambiance scale and take the mittens off probe ambiance values.  Fix for sky brightening being done in sRGB space.

SL-19281 Unify handling of haze and gamma between fullbright and not and move haze back to sRGB color space to stay consistent with sky colors.  Also fix broken "roughness" stuck at 0.2.

SL-19228: Fix GLTF texture transform rotation and add UV debug (PBR only). See textureUtilV.glsl for UV coordinate comments

SL-19080: Restrict LLGLTFMaterial fields test to a single compiler target, as results can vary between compilers

SL-19080: Update GLTF Material asset upload to v1.1, with stricter GLTF compliance and removal of unsupported features

LLUUID and LLMaterialID already have an excellent entropy and value dispersion; there is therefore strictly no need to further (slowly) hash their value for use with std and boost libraries containers.

This commit adds a trivial getDigest64() method to both LLUUID and LLMaterialID (which simply returns the XOR of the two 64 bits long words their value is made of), and uses it in std::hash and hash_value() specializations for use with containers.

This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.

Here is the comment I added in indra/llcommon/hbxx.h:

// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.

This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.

Here is the comment I added in indra/llcommon/hbxx.h:

// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.

Should be fixed by SL-18996, but just in case user decides to select a model while viewer closes

SL-18869, SL-18772  Overhaul VBO management, restore occlusion culling, intel compatibility pass, etc

SL-18820: Fix applying material clearing transform overrides. Loosen some asserts to allow non-default transform overrides.

And cleaned up dupplicate mScale code

Revert "SL-18523: When editing an object's material override, use the object's material override as a base, rather than its render material (pull request #1190)"

SL-18523: When editing an object's material override, use the object's material override as a base, rather than its render material