Should fix "Radio/Stream hiccups at a regular rate during playback"

```
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.

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.