fold_range() already invokes wi_fold_in_parts to try to get more refined 
information. If the subranges are quite small, it will do each 
individual calculation and combine the results.

x * y with x = [1,3] and y = [1,3]  is broken down and we calculate each 
possibility and we end up with [1,4][6,6][9,9] instead of [1,9]

We limit this as the time is between quadratic to exponential depending 
on the number of elements in x and y.

If we also check the relation and determine that x == y, we don't need 
to worry about that growth as this process is linear.  The above case 
will be broken down to just  1*1, 2*2 and 3*3, resulting in a range of 
[1, 1][4,4][9,9].

  In the testcase, it happens to be the right_shift operation, but this 
solution is generic and applies to all range-op operations. I added a 
testcase which checks >>, *, + and %.

I also arbitrarily chose 8 elements as the limit for breaking down 
individual operations.  The overall compile time change for this is 
negligible.

Although this is a regression fix, it will affect all operations where x 
== y, which is where my initial hesitancy arose.

Regardless, bootstrapped on x86_64-pc-linux-gnu with no regressions.  OK 
for trunk?

Andrew