This patch turns ranger on by default for the VRP1 pass.

I needed to adjust gcc.dg/pr68217.c to scan for a better range ([-INF, 
-INF][0, 0]) than the original [-INF, 0] it was looking for.

This also triggers the new __builtin_unreachable code in the ranger VRP 
pass, so I added a new testcase to show accumulated unreachables are 
combined properly.  tree-ssa/pr107009.c also verifies that a 
non-dominated unreachable call doesn't incorrectly affect the global range.

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

* OK. no regressions is debatable.  I've been seeing the following 
spurious failure for the past few weeks.  Ranger made them pass for a 
while, then made them fail, so Ive been ignoring them. I took a quick 
look.  Basically, we optimize away an unnecessary statement feeding a 
condition based on a combination of what ranger calculates and results 
from loop analysis.  (The statement is not referenced in any debug 
statement).  That later causes a PHI to no longer been needed, and DCE2 
removed the PHI and some other stuff, which then causes the debug_stmt 
to lose its reference.  /blame dce2 :-)

< FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 x == 10 - i
< FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 y == 20 - 2 * i
< FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i

I choose to ignore this for now...  I want to get VRP1 turned to ranger 
by default and see if any issues show up.  I believe this removes the 
last remaining use of legacy vrp.

Andrew