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.

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

Fix up slight change to Dullahan interface where we call out the platform for native keyboard injection to match OSX version

Pull in new version of p64_3p-Dullahan with support for flippyingh pixels/mouse, copy/cut/paste and new version info

First round of changes to replace LLCEFLib with Dullahan. Mostly Windows changes in this batch since I'm working on Windows box but some speculative macOS ones too although they are quite untested

This is already done for TeamCity builds in build.sh, but since we don't yet
have 64-bit Xcode 8 Mac Havok working in the viewer, make plain developer
autobuild builds work also.

converting to logging so that stdout from its command can be captured
cleanly
Make the default be to not print anything