This was the result of inconsistent use of PyMem_* and PyObject_* allocators.
By changing to use PyObject_* allocator almost everywhere, this removes
the inconsistency.

Change the parser and compiler to use PyMalloc.

Only the files implementing processes that will request memory
allocations small enough for PyMalloc to be a win have been
changed, which are:-
 - Python/compile.c
 - Parser/acceler.c
 - Parser/node.c
 - Parser/parsetok.c

This augments the aggressive overallocation strategy implemented by
Tim Peters in PyNode_AddChild() [Parser/node.c], in reducing the
impact of platform malloc()/realloc()/free() corner case behaviour.
Such corner cases are known to be triggered by test_longexp and
test_import.

Jeremy Hylton, in accepting this patch, recommended this as a
bugfix candidate for 2.2.  While the changes to Python/compile.c
and Parser/node.c backport easily (and could go in), the changes
to Parser/acceler.c and Parser/parsetok.c require other not
insignificant changes as a result of the differences in the memory
APIs between 2.3 and 2.2, which I'm not in a position to work
through at the moment.  This is a pity, as the Parser/parsetok.c
changes are the most important after the Parser/node.c changes, due
to the size of the memory requests involved and their frequency.

disaster too, so this change is here to stay.  Beefed up the comments
and added some stats Andrew reported.  Also a small change to the
macro body, to make it obvious how XXXROUNDUP(0) ends up returning 0.
See SF patch 578297 for context.

Not a bugfix candidate, as the functional changes here have already
been backported to the 2.2 line (this patch just improves clarity).

children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).

Bugfix candidate.

This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3.  Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method.  When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity.  This is aggressive over-allocation.

SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX.  Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs.  Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS:  as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.

I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size.  It also speeds
test_longexp in its unaltered state.

Fred, check this!

and this breaks the AIX build with an INT_MAX redefinition error.
"config.h" is included in pgenheaders.h, so moving this down fixes the
problem.

This should match the situation in the 1.6b1 tree.