Set a more consistent live range in rare cases.

This section of code deals with the rare case where a variable's live
range within a basic block consists of two segments with a gap in the
middle.  This can happen in a loop where the variable is set mid-block
but is a source operand for a Phi instruction at the beginning of the
block.

We set the latter segment's upper bound to be one past the last
instruction of the block to be consistent with other code that does
the same, and it also increases the chances of merging the segment
with the segment in the following block.
Fix a liveness bug.  Add a liveness validator.

The bug was that IceCfgNode::LiveBegin and LiveEnd were clear()ed but
not resize()d.  For some reason, subsequent [] operations were
silently succeeding.  I think some memory corruption may have been
going on, but it's a bit puzzling why this in particular led to
incorrect liveness.

The liveness validator traverses every IceVariable in every IceInst
and verifies that the instruction number is contained within the
variable's live range.  Currently it does not traverse the Phi
instructions but it probably should, though phi source liveness is a
bit weird -- if the Phi instruction ends its live range, then its live
range is actually marked to end at the end of the predecessor block.

I have one more suspected liveness bug, but I haven't been able to
find an example.  The liveness algorithm iterates until there are no
more changes in any basic block.  Changes are defined in terms of the
set of live variables at the start of the block.  However, if an
instruction is marked as tentatively dead, this affects liveness in
terms of recording the end of the live range, but it may ultimately
not affect overall liveness at the start of the block.  If this
problem shows up, the liveness validator should catch it.