Win32: Pass compiler switches from build file

For cases where we disable certain compiler warnings on Windows, do it
via command-line arguments to the compiler, rather than #pragma
declarations in the source.

The two specific warnings we disable are:

4090 'function': different 'const'

    This is disabled to work around false positives, where VC++
    correctly interprets the semantics of const in pointrs, confusing
    const char ** as something that can't be passed to free(), which we
    do a lot (it's actually valid; its the elements of the array that
    are const, not the array itself).

4996 // The POSIX name for this item is deprecated

    Because VC++ wants you to use _strdup instead of strup, and similar
    functions (for some stupid reason)
Start of a unit test scheme for internal functions

Up until now, we've had the .test files which invoke various functions
within the library like the get, put, and create operations. These
supply input data e.g. in the form of HTML or a .docx file (represented
in a plain-txt format), and the test functions operate on that data.

However, we also want to be able to have more granular unit tests
written entirely in C, for exaple testing that the substring function
works. Additionally, we want to test use case of the API functions, for
example checking that the DFGetFile function returns an error if the
specified file does not exist.

This commit is an initial attempt at a structure to address this latter
type of test. It defines data structures for representing test groups,
and functions that individual test cases can call to do things like
assertions, expected/actual comparisons, and explicit failures.

The test functions theselves do not return any values to indicate
success or failure. Rather, they call functions like the assertion
routine, and the test will pass or fail after the function returns and a
check is performed to see if any of these were called.

I would like to integrate this mechanism with the existing data file
approach whereby the file can specify the name of the test function to
be run, and the input is taken from that file and given to that
function. The current commit does not address this need yet.

A new program, dftest, has been added which can be used to run these
"internal" tests. All this does it grab references to the test groups
defined in various files (e.g. APITests.c) and run them with the
rudimentary test harness that is now built in to the DocFormats library
itself.