We were sometimes losing a splintering opportunity when a range was
ending at the beginning of a hot (==non-deferred) block, when giving
its value to some fixed range - i.e. a fixed operand of the first instruction
in that hot block.

Renamed 2 APIs to better reflect what their intent is.

Added self-checking when introducing moves connecting ranges, to
ensure we don't spill/fill in hot blocks ranges spilled only in deferred
blocks. Verified locally that these checks would have tripped in a few
cases before this change.

BUG=

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

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