Towards resolving issue #50.

Native x86-64 now has 3 locals in registers.

Fix some bugs with x86 stack and saving registers correctly.

This is required to deal with, well, packed C structs containing pointers.

Type representing signed size doesn't have to be int, so use special value
which defaults to SSIZE_MAX, but as it's not defined by C standard (but rather
by POSIX), allow ports to set it.

Previously, mpz was restricted to using at most 15 bits in each digit,
where a digit was a uint16_t.

With this patch, mpz can use all 16 bits in the uint16_t (improvement
to mpn_div was required).  This gives small inprovements in speed and
RAM usage.  It also yields savings in ROM code size because all of the
digit masking operations become no-ops.

Also, mpz can now use a uint32_t as the digit type, and hence use 32
bits per digit.  This will give decent improvements in mpz speed on
64-bit machines.

Test for big integer division added.

Script is equivalent, but now also runs under ancient Python 2.6.
Goes part way to addressing issue #847.

Code-info size, block name, source name, n_state and n_exc_stack now use
variable length encoded uints.  This saves 7-9 bytes per bytecode
function for most functions.

And move the MAP_ANON redefinition from py/asmx64.c to unix/alloc.c.

Fixes issue #840

Part of code cleanup, working towards resolving issue #50.

Part of code cleanup, working towards resolving issue #50.

Part of code cleanup, working towards resolving issue #50.

Part of code cleanup, to resolve issue #50.

Part of code cleanup, towards resolving issue #50.

Addressing issue #50, still some way to go yet.

Found this bug by running unix/ tests with DEBUG=1 enabled when
compiling.

Addresses issue #838.

Optimises:
    if () -> if False
    if (x,...) -> if True
    if (a and b) -> if a and b

This way, the native glue code is only compiled if native code is
enabled (which makes complete sense; thanks to Paul Sokolovsky for
the idea).

Should fix issue #834.

The heap allocation is now exactly as it was before the "faster gc
alloc" patch, but it's still nearly as fast.  It is fixed by being
careful to always update the "last free block" pointer whenever the heap
changes (eg free or realloc).

Tested on all tests by enabling EXTENSIVE_HEAP_PROFILING in py/gc.c:
old and new allocator have exactly the same behaviour, just the new one
is much faster.

Recent speed up of GC allocation made the GC have a fragmented heap.
This patch restores "original fragmentation behaviour" whilst still
retaining relatively fast allocation.  This patch works because there is
always going to be a single block allocated now and then, which advances
the gc_last_free_atb_index pointer often enough so that the whole heap
doesn't need scanning.

Should address issue #836.

Saves ROM (16 on stmhal, 240 on 64-bit unix) and should be quicker since
there is 1 less branch.

With a file with 1 line (and an error on that line), used to show the
line as number 0.  Now shows it correctly as line number 1.

But, when line numbers are disabled, it now prints line number 1 for any
line that has an error (instead of 0 as previously).  This might end up
being confusing, but requires extra RAM and/or hack logic to make it
print something special in the case of no line numbers.

Addresses issue #827.