```
autobuild installables edit "tracy" url="https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/110561/960415/tracy-v0.7.8.578230-darwin64-578230.tar.bz2" hash="70f31fa71ecb52bd092da52e27c3ff8c"
autobuild installables edit "tracy" url="https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/110562/960424/tracy-v0.7.8.578230-windows-578230.tar.bz2" hash="1dc33422939adf015db85e96c5a8276e"
autobuild installables edit "tracy" url="https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/110563/960429/tracy-v0.7.8.578230-windows64-578230.tar.bz2" hash="fcc6ecece2ecb65aa36500dfa9461fb3"
```

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.

Same apr suit version, but with debug symbols

Updated tinygltf package to use common package shared with all platforms as part of SL-17967 work for material overrides

Should fix some common crashes for parcel media

Openjpeg was modified: "p_max_len -= l_nb_bytes_read;" was causing an overflow.
I'm not sure if I did something incorectly in opj_skip/opj_seek viewer side, but seems like openjpeg should have been checking remaining space in p_max_len either way.
P.S. Many thanks to Chafey and Neopallium for implementing openjpeg's partial bitstream support

SL-18151 [SEC] MOAP can force multiple floaters open on users screen: The Viewer part of the fix for this JIRA - pulls in the updated Dullahan that exposes the user_gesture/is_redirect flags and uses them to determine what type of 'nav_type' is exchanged with viewer/plugin

SL-18095 WIP -- Add Mikktspace tangent generation for PBR materials and switch to per-pixel binormal generation.  Still bugged with some test content.

Nicky Dasmijn's contribution for zlib-ng Linux builds