fix for MAINT-6998 64bit viewer installs to Program Files (x86) by default. - this change also fixes MAINT-5365 Windows viewer uninstall icon is system default not SL logo

Fix for MAINT-7131 Unable to start the x64 Viewer on Windows 8.1 x64.  This appears to be because two of the MS DLLs we ship with the 64 bit viewer are 32bit. Manually replacing them with their 64 bit equivalents allowed the viewer to start on Windows 8.1.  The change forces the cmake file which copies the DLLs to look in C:\windows\SysWOW64 for 32 bit versions and C:\windows\system32 for 64 bit versions. (yes really).

Additional work on : Fix for MAINT-7054 Viewer Crashed when I used Japanese IM. (Drake and Appurist convinced me my initial solution was non-optimal)

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