Improve evaluate-ahead heuristic

Bug: 21447808

This changes the existing heuristics to compute ahead significantly
more aggressively.  In my testing, this typically managed to prevent
blanks from being displayed even during rapid scrolling.  We start
the next computation once we get near the end of what we've
currently computed.  By the time we get to the end, the new
results are ready.

With this change, we typically compute to nearly 100 digits even
without scrolling, and the amount we compute ahead increases as
we've scrolled further.  With the previous asin() CL, that seems to be
fine.  I suspect, but have not confirmed, that for this size
BigInteger operations, much of the latency is fixed, e.g. JNI,
overhead, and the number of digits is not yet critical anyway.

This should reduce the total amount of computation, and hence battery
usage, during "extreme scrolling", since the evaluation precision
now increases geometrically.

Update a copyright notice.

Change-Id: If3a162016b8ffbacc872361aaa99c77c7fd578a2