The previous LLSafeHandle<T> implementation declares a static data member of
the template class but provides no (generic) definition, relying on particular
specializations to provide the definition. The data member is a function
pointer, which is called in one of the methods to produce a pointer to a
"null" T instance: that is, a dummy instance to be dereferenced in case the
wrapped T* is null.

Xcode 8.3's version of clang is bothered by the call, in a generic method,
through this (usually) uninitialized pointer. It happens that the only
specializations of LLSafeHandle do both provide definitions. I don't know
whether that's formally valid C++03 or not; but I agree with the compiler: I
don't like it.

Instead of declaring a public static function pointer which each
specialization is required to define, add a protected static method to the
template class. This protected static method simply returns a pointer to a
function-static T instance. This is functionally similar to a static
LLPointer<T> set on demand (as in the two specializations), including lazy
instantiation.

Unlike the previous implementation, this approach prohibits a given
specialization from customizing the "null" instance function. Although there
exist reasonable ways to support that (e.g. a related traits template), I
decided not to complicate the LLSafeHandle implementation to make it more
generally useful. I don't really approve of LLSafeHandle, and don't want to
see it proliferate. It's not clear that unconditionally dereferencing
LLSafeHandle<T> is in any way better than conditionally dereferencing
LLPointer<T>. It doesn't even skip the runtime conditional test; it simply
obscures it. (There exist hints in the code that at one time it might have
immediately replaced any wrapped null pointer value with the pointer to the
"null" instance, obviating the test at dereference time, but this is not the
current functionality. Perhaps it was only ever wishful thinking.)

Remove the corresponding functions and static LLPointers from the two classes
that use LLSafeHandle.

When a 'family' code isn't recognized, for instance, report the family code.
That should at least clue us in to look up and add an entry for the relevant
family code.

Next part of the 'SL-641 Update CEF -> cef-bin -> Dullahan -> p64_3p-Dullahan -> media_plugin_cef.cpp to current latest version' puzzle - fix @rpath/@executable paths for macOS

SL-641 - Update CEF -> cef-bin -> Dullahan -> p64_3p-Dullahan -> media_plugin_cef.cpp to latest versionPull in p64_3p-dullahan that has the cef 2897/chrome 57

LLEventPump's destructor was using LLEventPumps::instance() to unregister the
LLEventPump instance from LLEventPumps. Evidently, though, there are lingering
LLEventPump instances that persist even after the LLSingletonBase::deleteAll()
call destroys the LLEventPumps LLSingleton instance. These were resurrecting
LLEventPumps -- pointlessly, since a newly-resurrected LLEventPumps instance
can have no knowledge of the LLEventPump instance! Unregistering is
unnecessary!

What we want is a reference we can bind into each LLEventPump instance that
allows us to safely test whether the LLEventPumps instance still exists.
LLHandle is exactly that. Make LLEventPumps an LLHandleProvider and bind its
LLHandle in each LLEventPump's constructor; then the destructor can unregister
only when LLEventPumps still exists.

Apparently we've been getting away so far without this essential #include only
by "leakage" from other #includes in existing consumers. <eyeroll/>

LLUpdaterServiceImpl binds its onMainLoop() listener method to the "mainloop"
event so it can wake up periodically to recheck for updates. (Suggests maybe a
smarter conventional callback-on-timer facility with a central queue, instead
of every interested party intercepting *every* frame...)

~LLUpdaterServiceImpl() was calling LLEventPumps::instance() only to
disconnect that listener, which was resurrecting the deleted LLEventPumps
instance. Instead store an LLTempBoundListener in LLUpdaterServiceImpl, the
conventional way to implicitly disconnect on destroy. Use its disconnect()
method when explicit disconnection is desired.

The logging subsystem depends on two different LLSingletons for some reason.
It turns out to be very difficult to completely avoid executing any logging
calls after the LLSingletonBase::deleteAll(), but we really don't want to
resurrect those LLSingletons so late in the run for a couple stragglers.
Introduce LLSingleton::wasDeleted() query method, and use it in logging
subsystem to simply bypass last-millisecond logging requests.

The LLSingletonBase::deleteAll() call late in LLAppViewer::cleanup() deletes
the LLSingleton(s) used by the logging machinery, among other things. Attempting
further logging after that call (such as our cheery "Goodbye!") has the
unfortunate effect of attempting to resurrect the deleted LLSingleton(s). Move
"Goodbye!" to just *before* the call.

Also, given that call, the manual references to a couple specific LLSingletons
in ~LLAppViewer() are (a) unnecessary and (b) cause attempted resurrection.
Eliminate both.

MAINT-6998 [Project Alex Ivy] 64bit viewer installs to Program Files (x86) by default. (Update2: evidently the registry set call is needed on un.init() too

MAINT-6998 [Project Alex Ivy] 64bit viewer installs to Program Files (x86) by default. (Update: call to select registry needs to be inside a function)

Update: (thanks Drake) MAINT-6998 [Project Alex Ivy] 64bit viewer installs to Program Files (x86) by default. Added option to engage 32 or 64 bit registry

Fix for MAINT-7047 No information about 32bit or 64bit version of 'Project Alex Ivy' viewer in non-English locales

Second part of fix for SL-646 Fix 'LINK : warning LNK4075: ignoring /INCREMENTAL due to '/LTCG' specification' in LibVLC, JPEGLIB etc.

Pull in 3rd party lib to fix: SL-646 ”LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification” in LibVLC, JPEGLIB etc.

Second Life SL-643 viewer_manifest.py still tried to copy the CEF file wow_helper.exe but it's no longer present