Fix concurrent start bytes race

Previously, we set concurrent start bytes to max int when we
requested a concurrent GC, but there was a race if another thread
was doing another GC and had already completed GrowForUtilization
but had not yet finished the GC. This meant that the thread doing
the GC would update the concurrent start bytes properly, but the
allocating thread would re-update it to max int. Then when the
concurrent GC thread woke up, it would call WaitForGcToComplete
and see that there was a collector running and avoid doing the
concurrent GC, leaving the concurrent start bytes set to max int.

This meant that there would be no more concurrent GC until either
the next explicit GC or the next GC for alloc.

The fix is to only set concurrent start bytes to max int inside of
the CollectGarbageInternal code such that there isn't any way for
two threads to race.

Bug: 17942071

(cherry picked from commit 0133ec454d8dd3fa5ffe35649b5704aa18f15a49)

Change-Id: Ibc23dd2f937a2b5fda51ed064634c034dbb6e668

(cherry picked from commit 438c7ffaa4b9d651b980e90245659a535f77e03a)
Move GC daemon locking logic into heap

Fixes deadlock caused by acquirng the mutator lock while
synchronizing on the daemon thread.

Bug: 18739541
Change-Id: I925b8f0f3b58178da6eff17b9c073f655c39597b

Conflicts:
	runtime/gc/heap.cc
	runtime/gc/heap.h

(cherry picked from commit 6858f91a416a26d00e61edb0407648f75adc551f)
Increase default allocation stack size

Prevents some GC for alloc which can occur if the allocation stack
overflows.

Bug: 18707404

(cherry picked from commit 4911153db37264de407b2a08c2e4c9bb6aef3545)

Change-Id: I4748485dd495526ab1a313f366d93dbb3ee8112b

(cherry picked from commit 6d3574760bd6bd7d36cac49cfc357a0660831ae7)
LOCAL_NO_LTO_SUPPORT := true