- If another DLL being loaded spawns a thread that begins doing I/O,
  then there is a race condition where `hook_table_apply` is still
  applying the hooks and has not returned yet but the hooked functions
  are called by those other threads. This causes the assert on
  `iohook_initted` to trigger.

- The easy fix is to always enter the mutex to ensure the hooks have
  been applied and function addresses for `CreateFileW` and
  `SetFilePointerEx` have been resolved.

This provides a replacement for iohook_open_dummy_fd() whose error
handling is more consistent with the rest of this library.

Meson has its own mechanisms for configuring warning levels.

Newer MSVC seems to use a different preprocessor symbol to denote
64-bit builds.

Newer versions of Meson introduce a more reliable way to detect
the compiler's expected command-line argument style.

Newer versions of Meson create this automatically for MSVC builds.

I forgot to update the Meson version for the past few releases.
whoops.

These assertions don't seem to hold for certain real ioctl errors.

Project now builds in Visual Studio 2017, probably earlier versions
too as long as they support enough of C99.

The loaded module list is kept in the order the modules are first
loaded. Using the first loaded module (i.e. the EXE) will help
ensure that multiple hook DLLs stack correctly. Previously the link
was taken from the most-recently loaded module.

Start address goes in RCX in 64-bit mode, EAX in 32-bit mode.