Update boost to codeticket version 533684.
Update colladadom to codeticket version 533705.
Update googlemock to codeticket version 533706.

Now that we have the Sync class to help construct unit tests that move forward
in a deterministic stepwise order, we can build suitable unit tests for
LLMainThreadTask.

Actually, introduce static LLCoros::logname() and make the namespaced free
function an alias for that.

Because CoroData is a subclass of LLInstanceTracker with a key, every instance
requires a distinct key. That conflicts with our "getName() returns empty
string for default coroutine on thread" convention. Introduce a new CoroData
constructor, specifically for the default coroutine on each thread, that
initializes the getName() name to empty string while providing a distinct
"mainN" key. Make get_CoroData() use that new constructor for its thread_local
instance, passing an atomic<int> incremented each time we initialize one for a
new thread.

Then LLCoros::logname() returns either the getName() name or the key.

Using Sync with multiple threads is trickier than with coroutines. In
particular, Sync::bump() was racy (get() and set() as two different
operations), and threads were proceeding when they should have waited.

Fortunately LLCond, on which Sync is based, already supports atomic update
operations. Use that for bump().

But to nail things down even more specifically, add set(n) to complement
yield_until(n). Using those methods, there should be no ambiguity about which
call in one thread synchronizes with which call in the other thread.

The new LLCoros::Stop exception is intended to terminate long-lived coroutines
-- not interrupt mainstream shutdown processing. Only throw it on an
explicitly-launched coroutine.

Make LLCoros::getName() (used by the above test) static. As with other LLCoros
methods, it might be called after the LLCoros LLSingleton instance has been
deleted. Requiring the caller to call instance() implies a possible need to
also call wasDeleted(). Encapsulate that nuance into a static method instead.

The LLTHROW() abstraction allows us to enrich the subject exception with a
boost::stacktrace -- without having to propagate the boost/stacktrace.hpp
header throughout the code base.

To my delight, our existing use of
boost::current_exception_diagnostic_information() already reports the newly
added boost::stacktrace information -- we don't have to query it specifically!

llexception_test.cpp is about discovering appropriate infrastructure to get
good information from the LLTHROW() and LOG_UNHANDLED_EXCEPTION() mechanism.
But we didn't before have a test that actually exercises them. Now we do.

LLStacktrace has no behavior except when you stream an instance to a
std::ostream. Then it reports the current traceback at that point to the
ostream.

This bit of indirection is intended to avoid the boost/stacktrace.hpp header
from being included everywhere.

Earlier versions of macOS manifested frustrating problems in finishing the
built package. Those build steps seem to have been behaving better for a few
years now. Eliminate (what we fervently hope has become) a bit of ancient cruft.

The new close(void) method simply acquires the logic from
~LLCoprocedureManager() (which now calls close()). It's useful, even if only
in test programs, to be able to shut down all existing LLCoprocedurePools
without having to name them individually -- and without having to destroy the
LLCoprocedureManager singleton instance. Deleting an LLSingleton should be
done only once per process, whereas test programs want to reset the
LLCoprocedureManager after each test.

Sometimes it's useful to be able to temporarily override an existing LOGFAIL
setting in the current environment. It's far more convenient to prepend
LOGFAIL='' to a command than to 'unset LOGFAIL' as a whole separate command --
and then remember to restore its previous value.

We've observed buffered_channel::try_push() hanging, which seems very odd. Try
our own LLThreadSafeQueue instead.

Reinstate LLCoprocedureManager::countPending() and count() methods. These were
removed because boost::fibers::buffered_channel has no size() method, but
since all users run within a single thread, it works to increment and
decrement a simple counter.

Add count information and max queue size to log messages.

But leave LLTempRedirect available in the code base.

LLSD::emptyMap() is a factory for an empty map instance, NOT a predicate on
any particular instance. In fact checking configuration.isUndefined() and
testing whether the map is empty are both subsumed by (! configuration).

That way, if there's a problem, a developer can rerun the same command.

Specify all of msvcp$VER.dll, msvcr$VER.dll and vcruntime$VER.dll -- but check
each of them individually, because any given VS release has only a subset of
those. Add messaging to clarify what we're doing.

Introduce to_staging_dirs CMake macro to cut down on redundant boilerplate:
the idiom in which we use copy_if_different twice, once to the Release staging
directory and once to the RelWithDebInfo staging directory, each time
appending the target pathnames to third_party_targets. Replace that idiom with
calls to to_staging_dirs.

However, this is not the right moment to perform that refactoring.

Evidently, with VS 2017, what would have been msvcr140.dll has become
vcruntime140.dll instead. msvcr140.dll is no longer a good sample DLL for
which to search.

Thanks NickyD.

Also forget obsolete references to VS 2010 runtime DLLs.

LLAppViewer's heap LLWatchdogTimeout might be destroyed very late -- as late
as in LLAppViewer's destructor. By that time, LLAppViewer::cleanup() has
already called LLSingletonBase::deleteAll(), destroying the LLWatchdog
LLSingleton instance.

But LLWatchdogTimeout isa LLWatchdogEntry, and ~LLWatchdogEntry() calls
stop(), and stop() tries to remove that instance from LLWatchdog, thus
inadvertently resurrecting the deleted LLWatchdog. Which is pointless because
the resurrected LLWatchdog has never heard of the LLWatchdogTimeout instance
trying to remove itself.

Defend LLWatchdogEntry::stop() against the case in which LLWatchdog has
already been deleted.