Fix concurrent GC ergonomics

Fixed a race with the gc_request_pending_ boolean which would cause
two concurrent GCs to start in a row in most cases. This broke sticky
CMS ergonomics since the second GC was a sticky CMS which started way
too early resulting in low throughput. Since the throughput was low,
it switch to partial / full for the next iteration.

The race happened as follows, allocating thread would request
concurrent GC which woke up the daemon thread. The daemon thread
cleared the gc_request_pending_ boolean, but before we set the
concurrent_start_bytes_ to max in to prevent more request, the
allocating thread would call RequestConcurrentGC again. This caused
the next WaitForConcurrentGCRequest to return right away and a
concurrent GC to occur earlier than necessary.

Changed the allocation rate ergonomics to use allocation rate
during the GC instead of allocation rate inbetween GCs, this is
better since the allocation rate may become slower if the GC steals
mutator time, resulting in concurrent GCs starting a bit earlier
than they need to.

Fixed a bug in GrowForUtilization where we didn't use the adjusted
max_free when we shrank down the heap, this caused the sticky CMS to
occasionally shrink the heap more than necessary.

EvaluateAndApplyChanges:
Before: ~12.6s GC time
After: ~7.75s GC time

Change-Id: I354bc825b3c44ccfbfe867af0d437b17fe1fe022