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