I found this optimization opportunity when analyzing some pathological
compile-time examples. When tying together live ranges across control
flow boundaries, we used to repeatedly check if the top level range was
spilled in deferred blocks or not. This proved to be a hotspot in such
cases (i.e. the pathological compile time ones).

Because the analysis needs to progress block by block and not live range by live range, we cannot feasibly save per-range information to
remove the hotspot. Instead, we save this information when
constructing LiveRangeBounds.

The result is 2.5 to 7% improvement in the pathological cases, and a few
similar bonuses in perf in a couple of other benchmarks.

Also, opportunistically removed the loop counting the number of child
ranges, since we have that count from the new (post - refactoring)
range numbering technique.

BUG=

Review URL: https://codereview.chromium.org/1412573009

Cr-Commit-Position: refs/heads/master@{#32071}