When I first added relations to range_ops, I struggled with obfuscating 
the API too much by adding all of the 3 possible relations.  For 
simplicity, it seemed like only one was ever relevant, so elected to add 
one relation, and make it always the relation between the 2 known operands.

fold_range()    - relation passed  op1 REL op2
op1_range()    - relation passed  lhs REL op2
op2_range()    - relation passed  lhs REL op1

With some of the floating point enhancements, we've tripped over cases 
where its useful to know one or more of the relations.

This patch provides a new class in value_relation.h called 
"relation_trio" which packages up 3 relations into a single unsigned 
value, and allows them to be extracted by request.  I have changed all 3 
of the primary range-ops interface routines mentioned above to take a 
relation_trio object by value rather than a relation kind, and then each 
range_op routines explicitly asks for the relation it is looking for.

I have also audited the range-op and range-op-float routines to make 
sure that when op2_range invokes op1_range that we do the appropriate 
relation swapping.

There is virtually no performance impact by this, and it is now clear 
when looking at one of the range-ops routines exactly what relation it 
is using.   This seems much less confusing.

I have also adjusted the compute_operand[12]_range routines in GORI to 
also provide a second relation when appropriate.

Bootstrapped on  x86_64-pc-linux-gnu with no regressions. Pushed.

Andrew