Add internal-to-ACR management of the database secure tunnel.

- Instead of relying on SSHFS to set up an SSH port forward for the
  MySQL connection, extract PLINK.EXE from ACR_AssemblyLoader,
  deposit it into a temporary directory and manage the lifetime of
  a PLINK.EXE process to run the SSH port forward.  This removes
  the final dependency on a Linux companion instance for each game
  server, substantially reducing complexity & easing deployment.

  If the SSH tunnel is disconnected, the DatabaseConnector will
  automatically manage monitoring and reconnection by restarting
  the PLINK.EXE process should it exit.  Note that in this mode,
  the lifetime of the PLINK.EXE process is tied to the lifetime of
  nwn2server.exe at most; that is, when nwn2server.exe exits, if
  any PLINK.EXE process started by the DatabaseConnector was still
  present, then it will also be terminated.

- A server must set up the database tunnel in DatabaseConnector.ini
  in the NWNX4 directory for it to be used (otherwise behavior is
  the same as before).  There should be a CommandLine string value
  set under the [Settings] heading that designates the command line
  to launch PLINK.EXE with (excluding the PLINK.EXE path as the
  PLINK.EXE program is internally contained within the ACR).  If
  this value is not set, then the legacy behavior is retained,
  i.e. it is assumed that the tunnel is externally managed.

  See template 'Server_Files\nwnx4 directory\DatabaseConnector.ini'
  for an example.

- It is also necessary for a server to accept the SSH public key of
  the ALFA central server by manually starting a putty.exe instance
  as the user that nwn2server.exe runs as, and connecting to the
  ALFA central server, before PLINK.EXE will successfully connect.

- When the secure tunnel is managed by the DatabaseConnector, the
  xp_mysql.ini file must point the database connection to localhost
  on the port that a local port forward is set up with on the
  designated LINK.EXE command line (i.e., typically 3306).

- A future update will consider replacing the MySQL plugin entirely
  in lieu of the more reliable MySQL Connector/NET library that is
  used by the CLR script code (a simple matter of simply calling
  out to CLR script code for each of the database operations
  instead of calling out to the NWNX MySQL plugin).