In the fix for 6467870 logic was added to keep CCP from marching
through all the values in a type range when moving the boundaries. It
would saturate a range to it's limit instead of expanding it one at a
time but then it would filter the resulting type through the worst
case type. If the side of the range chosen to saturate was already at
it's limit and the other side was moving then this would end up
reverting the type to the original limits which started a death march.
In the failing case we have the range int:199999999..200000000 with
the limit_type int:0..200000000. The code in widen will chose to move
_hi to max_jint but then filtering the type through the limit puts _hi
back to 200000000 returning the original type. The transforms are
actually moving _lo so the next time around it's 199999998 and so on.
The problem is that widen doesn't know what the true limit is so it
thinks it's making progress but it's not. The fix I'm proposing is to
feed the limit type into widen so that it can use that as the bounds
instead of assuming max_jint/min_jint.

Tested with test case.