LLThread::currentID() used to return a U32, a distinct unsigned value
incremented by explicitly constructing LLThread or by calling LLThread::
registerThreadID() early in a thread launched by other means. The latter
imposed an unobvious requirement on new code based on std::thread. Using
std::thread::id instead delegates to the compiler/library the problem of
distinguishing threads launched by any means.

Change lots of explicit U32 declarations. Introduce LLThread::id_t typedef to
avoid having to run around fixing uses again if we later revisit this decision.

LLMutex, which stores an LLThread::id_t, wants a distinguished value meaning
NO_THREAD, and had an enum with that name. But as std::thread::id promises
that the default-constructed value is distinct from every valid value,
NO_THREAD becomes unnecessary and goes away.

Because LLMutex now stores LLThread::id_t instead of U32, make llmutex.h
#include "llthread.h" instead of the other way around. This makes LLMutex an
incomplete type within llthread.h, so move LLThread::lockData() and
unlockData() to the .cpp file. Similarly, remove llrefcount.h's #include
"llmutex.h" to break circularity; instead forward-declare LLMutex.

It turns out that a number of source files assumed that #include "llthread.h"
would get the definition for LLMutex. Sprinkle #include "llmutex.h" as needed.

In the SAFE_SSL code in llcorehttp/httpcommon.cpp, there's an ssl_thread_id()
callback that returns an unsigned long to the SSL library. When LLThread::
currentID() was U32, we could simply return that. But std::thread::id is very
deliberately opaque, and can't be reinterpret_cast to unsigned long.
Fortunately it can be hashed because std::hash is specialized with that type.

instead of a variable of type decltype(expression).

Using SHGetKnownFolderPath(FOLDERID_Fonts) in LLFontGL::getFontPathSystem()
requires new Windows #include files.

A variable with a constructor can't be declared within the braces of a switch
statement, even outside any of its case clauses.

Use LLStringUtil::getenv() or getoptenv() whenever we fetch a string that will
be used as a pathname.

Use LLFile::tmpdir() instead of getenv("TEMP").

As an added extra-special bonus, finally clean up $TMP/llcontrol-test-zzzzzz
directories that have been accumulating every time we run a local build!

The previous build declared a static std::ofstream; but the code that
determines the pathname for the log file is called so early that static
objects have not yet been constructed. Declare a pointer instead, and
instantiate it on demand.

This logic is essentially copy-and-edited from the same suspenders-and-belt
concerning APPDATA and CSIDL_APPDATA for SL-10153.

In that case, also update $APPDATA for child processes.

Clearly it's not obvious to maintainers that on the Mac, getAppRODataDir()
returns the app's Resources directory: in a number of places the code starts
with the executable directory and appends "../Resources" to find that.

I think the intention of (sDumpDir.rbegin() == mDirDelimiter.rbegin()) was to
test whether sDumpDir endsWith(mDirDelimiter). But those iterators will never
be equal. Instead, use LLStringUtil::endsWith().

On Windows, when logged in with a non-ASCII username, every one of the three
documented APIs -- SHGetSpecialFolderPath(), SHGetFolderPath() and
SHGetKnownFolderPath() -- fails to retrieve any pathname at all. We cannot
account for the fact that the oldest of these continues to work with the
release viewer and within a Python script (though not, curiously, from a
Python interactive session). With a non-ASCII username, they consistently fail
when called from an Alex Ivy viewer build: "The filename, directory name, or
volume label syntax is incorrect."

Empirically, with a non-ASCII username, the preset APPDATA and LOCALAPPDATA
environment variables are also useless, e.g. c:\Users\??????\AppData\Roaming
where those are, yup, actual question marks.

Empirically, the VMP is able to successfully call SHGetFolderPath() to
retrieve both AppData\Roaming and AppData\Local. Therefore, we make the VMP
set the APPDATA and LOCALAPPDATA environment variables to the UTF-8 encoded
correct pathnames. Instead of calling SHGetSomethingFolderPath() at all, make
LLDir_Win32 retrieve those environment variables.

Make LLFile::mkdir() treat "directory already exists" as a success case. Every
single call fell into one of two categories: either it didn't check success at
all, or it tested specially to exempt errno == EEXIST. Migrate that test into
mkdir(); eliminate it from call sites.

Make LLDir::append() and add() convenience functions accept variadic
arguments. Replace add(add()...) constructs, as well as clumsy concatenations
of directory names and getDirDelimiter(), with simple variadic add() calls.

which is required to free the pointer returned by SHGetKnownFolderPath().

SHGetSpecialFolderPath() is deprecated, and empirically it appears to be
failing when the user name contains non-ASCII characters. The relevant
Microsoft documentation pages recommend calling SHGetKnownFolderPath()
instead.

Also, the SHGetSpecialFolderPath() calls had no error checking or reporting,
which is why we can only say it "appears to be" failing. Make sure that if
SHGetKnownFolderPath() fails, at least we try to tell somebody about it.

MAINT-7691 Fixed cache not clearing correctly and incapability to find dump files in case of unicode path

Storing it in a U32 and then comparing it to std::string::npos isn't going to
work in 64 bit land.

In a 64-bit build, std::string::npos is way bigger than a U32.