This will guarantee we can build hammer with default arguments

This is proof that Hammer can be linked and used in a windows
program!

The workaround would now cause build failures in Appveyor as seem to
have pre-emptively applied it to their environments.

I'm not too happy about their handling of the issue. Seems fiddly.

Anyway this commit is now required to build on Appveyor.

It seems Appveyor's images have been changed. The builds could not
find standard library headers anymore.

It seems to be an interaction between MS' scripts and the Windows
Driver Kit that is installed there.

One way to disable this interaction is to rename the `wdf` folder to
some other name.

See:
- http://stackoverflow.com/questions/31862627/vs2015-cl-cant-find-crt-libs-stido-h-ctype-h-etc-when-building-on-command-l
- http://help.appveyor.com/discussions/problems/3062-problem-with-new-updates-visual-studio-2015-and-cmake
- https://github.com/appveyor/ci/issues/414

Since the port is not finished yet, we remove some source files
and the compilation of examples.

In order to guarantee that Hammer can build on Windows, an appveyor.yml
and associated build scripts will build hammer and its examples. The idea
is that as soon as the appveyor.yml exists in the repository, pull
requests that would impede Windows portability would be immediately
detected.

The scripts expect CL.EXE to be in the path, and will produce their
results in build/

The highest level of warning is enabled on CL.EXE, minus warnings that
bring CL.EXE to a level that ressembles C99. The only notable warning
that was disabled is the one that tells you about implicit truncating
conversions.

Hammer's source code has quite a few implicit conversions say from a 64bit
unsigned integer to a integer of a lesser size (signed or otherwise)