This is viewer-manager's DRTVWR-587-actions branch updated from the new master
branch.

This reverts commit 9d49edbc.

We define a specialization of LLSDParam<const char*> to support passing an
LLSD object to a const char* function parameter. Needless to remark, passing
object.asString().c_str() would be Bad: destroying the temporary std::string
returned by asString() would immediately invalidate the pointer returned by
its c_str(). But when you pass LLSDParam<const char*>(object) as the
parameter, that specialization itself stores the std::string so the c_str()
pointer remains valid as long as the LLSDParam object does.

Then there's LLSDParam<LLSD>, used when we don't have the parameter type
available to select the LLSDParam specialization. LLSDParam<LLSD> defines a
templated conversion operator T() that constructs an LLSDParam<T> to provide
the actual parameter value. So far, so good.

The trouble was with the implementation of LLSDParam<LLSD>: it constructed a
_temporary_ LLSDParam<T>, implicitly called its operator T() and immediately
destroyed it. Destroying LLSDParam<const char*> destroyed its stored string,
thus invalidating the c_str() pointer before the target function was entered.

Instead, make LLSDParam<LLSD>::operator T() capture each LLSDParam<T> it
constructs, extending its lifespan to the lifespan of the LLSDParam<LLSD>
instance. For this, derive each LLSDParam specialization from LLSDParamBase, a
trivial base class that simply establishes the virtual destructor. We can then
capture any specialization as a pointer to LLSDParamBase.

Also restore LazyEventAPI tests on Mac.

They do work fine on clang... unblocking the rest of the team during diagnosis.

following promotion of DRTVWR-578

# Conflicts:
#	autobuild.xml
#	indra/llcommon/tests/llleap_test.cpp
#	indra/newview/viewer_manifest.py

for new Windows code signing mechanism.

clang has gotten smart enough to recognize an inline attempt to store to
address zero. Fool it by storing to an address passed as a parameter, and pass
nullptr from a different source file.

Even though LLVersionInfo::getBuild() already returns a 64-bit int, various
consumers assumed it could fit into 32 bits. It was especially bad to pass it
to a classic C style varargs function. Only on a little-endian CPU, and only
because it was the last argument, the damage was limited to truncation --
instead of arbitrary undefined behavior.

Where the consumer doesn't support 64-bit ints, pass as string instead.

SL-20473 Add GenericStreamingMessage and dummy handler to suppress packet loss and log spam noise when visiting GLTF enabled regions.

This includes this week's CEF 118.

The header file documents that no llrand function should ever return a value
equal to the passed extent, so the one test in llrand_test.cpp that checked
less than or equal to the high end of the range was anomalous.

But changing that to an exclusive range means that we no longer need separate
exclusive range and inclusive range functions. Replace
ensure_in_range_using(), ensure_in_exc_range() and ensure_in_inc_range() with
a grand unified (simplified) ensure_in_range() function.

Add python 3.12 to FindPython search path

Partially reverts SL-20206 commit 25388312

Look for python 3.12 in the registry along with all the other versions.

glext, which contains only header files, now builds only a single common
package instead of platform-specific ones. But as long as we retain the
platform-specific URLs, autobuild will continue to prefer those over the
common platform. Remove all platform-specific glext package entries.

It's frustrating and unactionable to have a failing test report merely that
the random value was greater than the specified high end. Okay, so what was
the value? If it's supposed to be less than the high end, did it happen to be
equal? Or was it garbage? We can't reproduce the failure by rerunning!

The new ensure_in_exc_range(), ensure_in_inc_range() mechanism is somewhat
complex because exactly one test allows equality with the high end of the
expected range, where the rest mandate that the function return less than the
high end. If that's a bug in the test -- if every llrand function is supposed
to return less than the high end -- then we could simplify the test logic.