add a missing end-of-input check in the LL(k) backend

Platform compilation improvement (windows port)

We have now again two functions called h_platform_vasprintf and
h_platform_asprintf. On windows they are implemented in terms of vsnprint
and the like. On BSD/GNU libraries we use the supplied vasprintf and
asprintf.

Since the block of code has been disabled anyway and is not very
portable, we introduce a define to control both the include
and the code.

Storing the size of the blocks is now only activated when DEBUG__MEMFILL
has been defined.

We replace instances of void* w/ char* arithmetics.

This allows system_allocator.c to be compiled with MSVC.

Also we introduce a struct to represent the size_t header.

We use QueryPerformanceCounter which will return realtime, not user
time.

We now have a `stopwatch` to measure time between two moments.

Building on appveyor

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

Some of them are completely spurious however some (marked FIXME(windows))
may benefit from being looked at.

This BSD call will have to be implemented on windows. Right now
we have a stub that just exits the process.

We wrap all remaining references to __attribute__ into a macro call to
H_GCC_ATTRIBUTE, to allow compilation with MSVC CL.EXE

We substitute H_GCC_ATTRIBUTE to any occurence of __attribute__ and
disable its function with non gcc, non clang compilers.

We use a H_ macro so as to not pollute users' namespaces.

On windows build without c4201 so as to allow anonymous struct. This
shows hammer is not C99 compliant but rather C11.

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)

Fix #133