Mostly trailing whitespace at the end of lines

Make some of the first steps to be able to build parts of ACRE on other
platforms (such as GCC).

Mostly, this amounts to differences in preprocessors, and some builtins.

This allows ACRE2Core, ACRE2Shared, and ACRE2Wine to be built under
Linux toolchains.

We gate DirectX inclusion to Windows only; on Linux, we include FAudio
as a drop in replacement for x3daudio. .pdb debugging symbols generated
on the Windows build are not copied on Linux. PIC has been flipped on
for Shared and Core on Linux.

ACRE2Arma, ACRE2TS, ACRE2Steam, and the utility modules are not built on
Linux, and it doesn't really make sense for them to be.

Some Windows types and functions have been aliased for compilation on
Linux.

FilterPosition relies on x3daudio to do positional transformations. On
Linux, we can use FAudio as an (almost) drop-in replacement.

Intel TBB is available as a library on Linux, under the `tbb` namespace,
rather than the `concurrency` namespace as on Windows.

ACRE's config file will be stored in $XDG_CONFIG_HOME (~/.config), as
per the XDG standard. Temporary files are stored in /tmp/acre-${USER},
and logs in $XDG_DATA_HOME (~/.local/share).

This tends to be Linux desktop users expect.

Replace some Windows specific string functions with cross-compatible
ones, and don't try to pop up message boxes on Linux.

An unused sddl.h include has also been removed

If the default path baked into the constructor is not the same as one
that is later loaded, the user will end up with two config files! Only
one will be used.

There is no need to load the config file in the constructor, however.
Hardcoded defaults are already set, and users of the class all load
config files explicitly.

This is the most involved change in this changeset.

On Linux, Arma runs under WINE, but Mumble is native. There's no (known
to me) way to do IPC between WINE processes and native processes; WINE
makes it (purposefully?) difficult.

It may be possible to use Windows 10+ Unix socket compatibility (if WINE
supports it), or some other mechanism. But this solution uses a simple
duplex network socket listening on localhost, with a default port of
19141. The Mumble side is responsible for setting up the server, and the
Arma side connects.

ACRE uses Windows named pipes in "message" mode, which means rather than
a stream of bytes, senders send a stream of messages and receivers
receive whole messages, not partial messages.

This is not the case with a TCP socket, and so a simple length encoding
is used. Whenever a sender has a message to send, they first send a four
byte unsigned integer that is the length of the message to come, and the
receiver first reads exactly four bytes, decodes the length of the
message, then reads exactly that many bytes.

The code is written to be tolerant (as in: will not crash, and will
simply drop the connection and wait for the otherside to reconnect) to
network faults and partial sends/receives. However, given that the
client and server are on the same networking stack, conditions are
ideal: sends and receives should match up exactly, and faults should be
impossible.

Since the port chosen could conflict with another server, possibly
another instance of Mumble/Acre/Arma, it is configurable. On the Mumble
side, it can be configured in the ACRE config file. On the Arma side, it
will be specified as a CBA setting and passed in to the extension via
a parameter to callExtension.

When running in Wine, ACRE2Arma.dll will mirror the changes to
NamedPipeServer.cpp for Linux; instead of using named pipes, it will
connect to the socket opened on the other side.

A helper function has been added to detect if running under Wine, by
checking for a function Wine defines in ntdll.

Also, publish the resulting Linux/Mumble plugin

This is how I intended it, but during a rewrite/rebase it got screwed
up.

The atof function is locale dependent. Specifically, it uses the
locale-specific decimal separator to convert floating-point strings;
that is, in a locale that uses commas as decimal separators, "0,5" will
convert to 0.5, whereas "0.5" will fail, and convert as 0.0. Strings
coming from Arma will always use a period as a decimal separator, this
causes myriad failures.

On Linux, on startup, we now set LC_NUMERIC to C, which has the behavior
we want.

I'm not certain why this isn't a problem on Win32. There may be a path
in Qt/Mumble that sets locale one way on Linux and another on Windows.

Instead of hardcoding the filenames of the destination files for
plugins, VOIPPlugin::handle_update_plugin will now use the basenames of
the x32 and x64 plugins paths passed into it.

If running under Wine, ACRE2Steam will now detect that and automatically
install the Linux Mumble plugin to the Linux version of Mumble, if it is
present.