removed checked in configure and other autotools products

People wishing to build gperftools from svn checkout should run
autogen.sh first which will create those files and then ./configure &&
make as usual
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,443}: allocate metadata in big batches

It uses same approach as PageHeapAllocator. Namely allocates big chunk
which is then used to satisfy smaller allocations.

In issue-443 gradual heap grows causes old code that allocates
metadata in smaller pieces and thus more frequently to fragment the
heap. It's also causing most of 368 heap fragmentation too.

New code allocates 8 megs of address space at once for metadata
allocations. Most OSes will allocate actual memory only when
corresponding pages are touched. Thus this change should not cause
increased memory usage.

I've also made sure metadata is always properly aligned in case we
ever allocate something that breaks natural alignment. E.g. strings.
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
dll-export TCMalloc_System{Alloc,Release}

because tcmalloc_unittest is using them
grab lock around new MetaDataAlloc internals