LazyEventAPI is a registrar that implicitly instantiates some particular
LLEventAPI subclass on demand: that is, when LLEventPumps::obtain() tries to
find an LLEventPump by the registered name.

This leverages the new LLEventPumps::registerPumpFactory() machinery. Fix
registerPumpFactory() to adapt the passed PumpFactory to accept TypeFactory
parameters (two of which it ignores). Supplement it with
unregisterPumpFactory() to support LazyEventAPI instances with lifespans
shorter than the process -- which may be mostly test programs, but still a
hole worth closing. Similarly, add unregisterTypeFactory().

A LazyEventAPI subclass takes over responsibility for specifying the
LLEventAPI's name, desc, field, plus whatever add() calls will be needed to
register the LLEventAPI's operations. This is so we can (later) enhance
LLLeapListener to consult LazyEventAPI instances for not-yet-instantiated
LLEventAPI metadata, as well as enumerating existing LLEventAPI instances.

The trickiest part of this is capturing calls to the various
LLEventDispatcher::add() overloads in such a way that, when the LLEventAPI
subclass is eventually instantiated, we can replay them in the new instance.

LLEventAPI acquires a new protected constructor specifically for use by a
subclass registered by a companion LazyEventAPI. It accepts a const reference
to LazyEventAPIParams, intended to be opaque to the LLEventAPI subclass; the
subclass must declare a constructor that accepts and forwards the parameter
block to the new LLEventAPI constructor. The implementation delegates to the
existing LLEventAPI constructor, plus it runs deferred add() calls.

LLDispatchListener now derives from LLEventStream instead of containing it as
a data member. The reason is that if LLEventPumps::obtain() implicitly
instantiates it, LLEventPumps's destructor will try to destroy it by deleting
the LLEventPump*. If the LLEventPump returned by the factory function is a
data member of an outer class, that won't work so well. But if
LLDispatchListener (and by implication, LLEventAPI and any subclass) is
derived from LLEventPump, then the virtual destructor will Do The Right Thing.

Change LLDispatchListener to *not* allow tweaking the LLEventPump name. Since
the overwhelming use case for LLDispatchListener is LLEventAPI, accepting but
silently renaming an LLEventAPI subclass would ensure nobody could reach it.

Change LLEventDispatcher's use of std::enable_if to control the set of add()
overloads available for the intended use cases. Apparently this formulation is
just as functional at the method declaration point, while avoiding the need to
restate the whole enable_if expression at the method definition point.

Add lazyeventapi_test.cpp to exercise.

This anticipates C++17's std::apply(), and in fact once we detect C++17, we'll
just use that. But in C++14 we must still provide our own implementation.

to pick up generalized LLEventAPI add() methods and softer error handling.

Instead of checking whether an add() parameter is exactly LLSD or LLSDMap,
check whether it's convertible to LLSD -- which handles those cases and more.

(cherry picked from commit fa168c11f64771dadc5df86d14ca2f07eba3b8ba)

Previously, LLEventAPI intentionally hid all but one of the many add()
overloads supported by its LLEventDispatcher base class. The reason was that
certain of the add() methods take an optional fourth parameter that's an
LLSD::Map describing the expected parameter structure, while others take a
fourth templated parameter that's an instance getter callable. This led to
ambiguity, especially when passed an LLSDMap instance that's convertible to
LLSD but isn't literally LLSD. At the time, it was simpler to constrain the
add() methods inherited from LLEventDispatcher.

But by adding new std::enable_if constraints to certain LLEventDispatcher
add() methods, we've resolved the ambiguities, so LLEventAPI subclasses can
now use any add() overload (as claimed on the relevant Confluence page).

LLEventDispatcher comments have always loftily claimed that an instance getter
callable may return either a pointer or a reference, doesn't matter. But it
does when trying to pass the getter's result to boost::fusion::push_back(): a
reference must be wrapped with std::ref() while a pointer cannot be.
std::ref(pointer) produces errors. Introduce LLEventDispatcher::invoker::
bindable() overloads to Do The Right Thing whether passed a pointer or a
reference.

(cherry picked from commit 743f487c2e123171c9fc6d5b84d768f1d856d569)

Originally the LLEventAPI mechanism was primarily used for VITA testing. In
that case it was okay for the viewer to crash with LL_ERRS if the test script
passed a bad request.

With puppetry, hopefully new LEAP scripts will be written to engage
LLEventAPIs in all sorts of interesting ways. Change error handling from
LL_ERRS to LL_WARNS. Furthermore, if the incoming request contains a "reply"
key, send back an error response to the requester.

Update lleventdispatcher_test.cpp accordingly.

(cherry picked from commit de0539fcbe815ceec2041ecc9981e3adf59f2806)

and registerTypeFactory().

Untested.

This will support registering just-in-time LLEventAPI instances, instantiated
on demand.

following promotion of DRTVWR-546

SL-17451 Fix for erroneous attempt to apply vertex color alpha to texture before alpha masking (we don't actually support this and the vertex color alpha is sometimes zero when you think it ought not be).

If there is no vcruntime140_1 in the build system, it is likely that file is not required for the viewer to run.

access violation, 'this' was null

# Conflicts:
#	indra/newview/llappviewer.h

following promotion of DRTVWR-550

- Do not try initializing shaders if requirements are not met or if window does not exist
- Warn user before closing window. Situation is unexpected, there is chance of more issues, like a freeze or a crash on close()
- mHasMultitexture is a solid requirement, if it is not present, we won't be able to run

SL-17239 Override face bounding box with avatar bounding box for rigged meshes when calculating virtual size.

LLWord should persist till the end due to wide usage.

Pausing clouds should not pause water

# Conflicts:
#	indra/llcommon/llsdutil.cpp
#	indra/newview/VIEWER_VERSION.txt
#	indra/newview/lldrawpoolalpha.cpp
#	indra/newview/lldrawpoolwater.cpp

following promotion of DRTVWR-540