fixed bogus unit test failure

Looks like my version of GCC is aware that free(malloc(X)) is a
no-op. So it optimizes that aware completely ignoring simple fact that
we're observing malloc hooks invocations. My adding check that malloc
succeeded we force gcc to actually preserve that malloc call.
use lowercase windows includes to enable x-compilation via mingw

I.e. so that I can build tcmalloc.dll using comfortable environment of
my GNU/Linux box and without having to touch actual windows box.
use gcc inline assembly atomic ops on mingw

Because those are well tested and can be trusted
don't try to typedef pid_t on mingw

Because recent mingws (more then few years ago seemingly) do that
already.
add AM_LDFLAGS to all *_la targets

Because automake will not automatically add AM_LDFLAGS if there's
per-target LDFLAGS. See their good info manual.

This fixes .dll compilation of tcmalloc
do not define HAVE_MMAP on mingw

Because, clearly, windows doesn't have one
disable tls on mingw

Which is known to fail.
issue-368: unmap free spans and retry before growing heap

Because unmapped spans are not coalesced with normal spans it's
possible that we indeed have a large enough free span, but we fail to
see that because we always consider unmapped and normal spans
separately. That behavior is more likely for larger spans.

Given that heap grows is not expected to be frequent event I believe
it's more than ok to spend some time trying to unmap everything we
have.

For same reason I believe even worst case is fine too. Basically new
code will cause whatever spans we had free but not big enough to
satisfy current allocation to incur minor page faults next time they
are allocated. But I believe alternative of memory blowup (where minor
page faults will occur anyway for newly grown span) is worse.
issue-368: batch allocations of pagemap metadata

Each time we grow heap by large span, there's a chance we will need to
allocate pagemap node to manage that new span. And because we
currently allocate metadata right after just allocated large span we
prevent that large span to be coalesced with next span we'll allocate
in next heap growth.

In order to fix that problem it's sufficient to preallocate some
pageheap metadata space. So that situation descibed above is
improbable, or at the very least not 100% certain.

Without this fix it's possible to have address space "wasted" by code
that does allocations/deallocations of growing chunks of
memory. I.e. because every next allocation will find existing free
span not big enough and allocate new. Without this patch all allocated
spans will have piece of memory used for metadata which will prevent
any coalescing and thus every malloc request will have to grow heap.
issue-368: test that don't fragment large spans too badly

This adds unit test that does essentially same things as code to
reproduce bug in
https://code.google.com/p/gperftools/issues/detail?id=368
implemented TCMalloc_SystemRelease for win32
regenerate autotools stuff