In Python 3.x

- int and long types are unified. The unified type is called int.
- the text string type (unicode) is renamed to str.
- the byte string type (str) is renamed to bytes.
- chr returns a text string (i.e. str)
- xrange is renamed to range.
- dict.has_key() is removed
-

These have no effect in Python 3.x, they are the default. Enabling them
in Python 2.x, enabling them in Python 2.x allows single source
compatiblity.

We disable:
- the tests (which require glib) although they can be
  reactivated with the `--tests` command line flag
- shared library (lack of export symbol declarations
  means that although it can be built, no symbol is
  exported and therefore it can't be used)

The `install` target installs the library and headers
under the `build` folder, because it's a traditional practice
to move libraries to a central location on Windows, unless
you are using cygwin. In which case pass `prefix` to the
command line.

We adapt tools\windows\build_examples.bat to take the library
that is built using scons or using tools\windows\build.bat

We port registry by importing the (public domain) openbsd implementation
of the tfind/tsearch POSIX binary tree search functions.

These are only necessary when building on non-posix platforms

MSVC was complaining that the `tail` variable was potentially
uninitialized in the while branch. Since the while loop is actually
coupled to the if (head != NULL) that initializes the tail variable,
we move them together, which makes the warning disappear.

The last file to port for the library is registry.c

It is the counterpart to c4018 for x64 compilations.

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.

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.

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)

Create a pkg-config file and install it to $prefix/lib/pkgconfig