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