This patch implements suggestion 1) from the PR:

    1) We unconditionally write the new value calculated to the global
    cache once the dependencies are resolved.  This gives it a new
    timestamp, and thus makes any other values which used it out of date
    when they really aren't.   This causes a lot of extra churn.

    TODO: This should be changed to only update it when it actually
    changes.  Client code shouldn't have to do this, it should be
    handled right int the cache's set_global_value ().

It turns out it is about a 3% compilation speed hit to compare the 
ranges every time we set them, which loses any gains we see. As such, I 
changed it so that set_global_range takes an extra parameter which 
indicates whether the value has changed or not. In all cases, we have 
the result of intersection which gives us the information for free, so 
we might as well take advantage of it.  instead we get about a 2.7% 
improvement in speed in VRP and another 0.7% in threading.

set_global_range now checks the changed flag, and if it hasnt changed, 
checks to see if the value is current or not, and only gives the result 
a new timestamp if its out of date.  I found many cases where we
   1) initally calculate the result, give it a timestamp,
   2) then evaluate the dependencies.. which get fresher timestamps than 
the result
   3) the initial result turns out to still be right, so we dont have to 
propagate the value or change it.

However, if we do not give it a fresh time stamp in this case, it wil be 
out of date if we ever check is sine the dependencies are fresher.   So 
in this case, we give it a new timestamp so we wont re-evaluate it.

The 3 patches together result in VRP being just 0.15% slower, threading 
being 0.6% faster, and overall compilation improves by 0.05%

It will also compile the testcase from the PR with issues after 
reverting Aldy's memory work and using int_range_max as int_range<255> 
again.. so that is also an indication the results are worthwhile.

At this point, I don't think its worth pursuing suggestion 4 from the 
PR.. it is wrought with dependency issues that I don't think we need to 
deal with at this moment.  When I have more time I will give it more 
consideration.

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

Andrew