In Python 2.x an unprefixed string literal produces a byte string.
In Python 3.x an unprefixed string literal produces a textual string.

To produce a byte string in both a b prefix is needed, e.g. b'foo'.
Since I believe Hammer works predominantly with byte strings I have used
b prefixes throughout.

This removes any doubts about what type of string is in use.

This allows the library to be built and tested with a non-default
version of CPython, e.g.

scons bindings=python python=python3.6
scons bindings=python python=python3.6 testpython

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.

I did this in a hurry, but it appears to work locally. I tested it with
a couple boring custom token type printers.

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 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.

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