build on Windows with scons

This will guarantee we can build hammer with default arguments

To homogenize the file and allow keys/strings to be searched easily.

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 will need to use the environment's CC variable to make decisions
that apply to windows compiling and linking. Therefore we move some
existing sections below the set up of env["CC"] and env["CXX"]

Finish porting parsers to windows

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

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

As MSVC doesn't implement C99, variable-length arrays
are not supported. We use _alloca instead.

It is the counterpart to c4018 for x64 compilations.

Added Python versions of base64 examples

Some combinators may report the wrong amount of consumed input

disable warning on windows about '..' in include paths

Handle memory allocation failures gracefully

These are transliterations of the existing C files.
They're not particularly Pythonic or performant, but they're a start.

Example of usage

```
$ echo '  YW55IGNhcm5hbCBwbGVhcw==' | PYTHONPATH=../build/opt/src/bindings/python/ python base64.py
inputsize=27
input=  YW55IGNhcm5hbCBwbGVhcw==
((((89L, 87L, 53L, 53L), (73L, 71L, 78L, 104L), (99L, 109L, 53L, 104L), (98L, 67L, 66L, 119L), (98L, 71L, 86L, 104L)), (99L, 'w', '=', '=')),)
$ echo '  YW55IGNhcm5hbCBwbGVhcw==' | PYTHONPATH=../build/opt/src/bindings/python/ python base64_sem1.py
inputsize=27
input=  YW55IGNhcm5hbCBwbGVhcw==
(97L, 110L, 121L, 32L, 99L, 97L, 114L, 110L, 97L, 108L, 32L, 112L, 108L, 101L, 97L, 115L)
$ echo '  YW55IGNhcm5hbCBwbGVhcw==' | PYTHONPATH=../build/opt/src/bindings/python/ python base64_sem2.py
inputsize=27
input=  YW55IGNhcm5hbCBwbGVhcw==
(97L, 110L, 121L, 32L, 99L, 97L, 114L, 110L, 97L, 108L, 32L, 112L, 108L, 101L, 97L, 115L)
```

Rationale: "Basic allocation" refers to things outside of parsing proper,
mostly initialization. If such allocations fail, the system is globally
emory-starved from which it will likely not recover by returning failure.
In this case, terminating the process is in fact the most robust strategy as
it may mean the difference between a permanent hang and a temporary crash.

Rationale: If memory allocation fails in the inner parse and we
longjump up the stack, the temporary arena will be missed and leak.

NB: This change means that any allocations done by the continuation
(in the form of new parsers, probably) will persist for the
lifetime of the parse result. Beware of wasting too much memory
this way! The bind continuation should generally keep dynamic
allocations to a minimum.

fix LIBPATH order for building test_suite