We push the context and the js function onto the stack as part of the
frame construction. The register allocator is presented with virtual
registers for the above as defined from their corresponding registers. It
then goes on to spilling them somewhere else on the stack.

This means each function spends two redundant spills and two
unnecessary stack slots.

This change addresses this issue.

We present these parameters (context and function) to the register
allocator as an UnallocatedOperand having a "secondary storage". The
secondary storage is then associated to the live range as its
spill operand. We capture the definition of the live range so that we can
then commit the spill (in this case, eliminate) through a variation of the
mechanics of the CommitAssignment phase.

The register allocator validator also needed update to understand
UnallocatedOperands with a secondary storage.

The change renames the SpillAtDefinitionList and related APIs to better
capture their intent - the old names suggested spills happened upon
calling. In reality, potential spill locations were thus recorded, and later
committed (or not, in certain cases) after register allocation.

BUG= v8:4548
LOG=n

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

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