Test timeout warnings are too strict

### Description of the problem / feature request:

When setting the test timeout there is a strict upper-bound and a weakly enforced lower bound. If the test runs below the lower bound then a warning is issued. There should be a way to better configure this range such that warnings are never issued.

### Feature requests: what underlying problem are you trying to solve with this feature?

I have a test which reads a lot of data from disk. If that data happens to be in cache, the test runs relatively quickly (for example 100-150s), but if the data isn't in cache the test can run much slower (for example 400-500s). Due to the latter case, I have to set timeout="long". But when it runs quickly I get a warning that is confusing to any other users. There should be a way to set the lower bound such that warnings are squelched over a wider range.

### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Run a simple test with randomly selected sleep 100s or sleep 400s.

### What operating system are you running Bazel on?

Red Hat EL6

### What's the output of `bazel info release`?

development version

### If `bazel info release` returns "development version" or "(@non-git)", tell us how you built Bazel.

### What's the output of `git remote get-url origin ; git rev-parse master ; git rev-parse HEAD` ?

### Have you found anything relevant by searching the web?

Unable to find anything on this particular issue

### Any other information, logs, or outputs that you want to share?

.

Start by reproducing the issue with a simple test that sleeps for either about 100 or 400 seconds, then trace where Bazel emits the test-timeout warning. Identify how the timeout range is configured and add coverage for a wider lower-bound range; done means the warning is suppressed for both reported runtimes without weakening the strict upper bound.

Written by the indexing model from the issue text.