When ranger was first written, it processed all the range-ops 
statements, and the remainder of the statements we slowly added, and 
shared as much code with vr_values as we could.

We are now at a point where it makes sense to split this out into its 
own class. There are a number of places where range-ops is treated 
"special" because it follows  a specific formula, and the other kinds of 
statements have becoming second class citizens.  By pulling all the 
statement processing out of gimple-ranger and into a class which handles 
the statements and uses general range queries, we can treat all the 
statements the same way. There are numerous benefits to this.

   1) with the upcoming relational work, I want to be able to query 
relations in builtin function processing (and other places) as well as  
range-ops.
   2) GORI is going to be enhanced so we can look back thru things other 
than range-ops statements... this will help with overflow analysis in 
builtins especially.
   3) simplified interface for anyone wanting to calculate a range.      
a new routine:
         bool fold_stmt (irange&r, gimple *s, range_query *q=NULL)
will do look-ups to and provide a range for the stmt.  This is now being 
used internally in ranger and can work with global ranges, or any kind 
of range_query.

All the various stmt kind processing is pulled out of gimple_ranger and 
moved into class fold_using_range, which has a single external API.  A 
helper class fur_source (FoldUsingRange_source) is used to provide a 
mechanism for the statement folder to resolve any ssa_names.  It can be 
set up to provide range queries from the original stmt location, on an 
edge, or from any arbitrary location.

This allows us to not only fold a stmt where it sits in the IL, but also 
gives us the power to recalculate a stmt as if it occurs somewhere 
else.  A second function is provided which specifies an edge, and the 
statement can be recalculated as if it was sitting on that edge.  It is 
also possible (and ranger uses this) to calculate the statement as it 
occurs elsewhere in the program.

This is useful for things like

    b_2 = a_1 + 10
    if (a_1 > 20 && a_1 < 40)
          c_5 = b_2 + 4

When ranger calculates a range for c_5, it recognizes that b_2 is 
dependant on the value of a_1, and a_1 has been "refined" since b_2 was 
defined.  So rather than using the original value of b_2, SSA allows us 
to recalculate b_2 at the location of the use... ie,  we know a_1 is 
[21, 39], so b_2 is recalculated at that use as [21,39] + 10 = [31,49] . 
The value of c_5 is then calculated as [31,49] + 4 = [35, 53].

This works with an arbitrary amount of IL between the statements since 
its driven by uses and defs.

This is the first of a set of cleanup/generalizations. Bootstraps on 
x86_64-pc-linux-gnu with no regressions.

Pushed.

Andrew