[WIP] Remove many uses of Thread.sleep() from streaming tests

This is a work-in-progress PR towards removing many of the `Thread.sleep()` calls from Spark Streaming's test suite, since I think that these calls make these tests race-prone and flaky.

**Running list of the JIRAs that this patch addresses / intends to address**:

- [SPARK-4835](https://issues.apache.org/jira/browse/SPARK-4835): "Streaming saveAs*HadoopFiles() methods may throw FileAlreadyExistsException during checkpoint recovery"
- [SPARK-1600](https://issues.apache.org/jira/browse/SPARK-1600): "Flaky "recovery with file input stream" test in streaming.CheckpointSuite"

**TODOS**:

- [ ] Fix SPARK-1600 by removing the `Thread.sleep` calls from the `recovery with file input stream` test.  There are several uses of `Thread.sleep` here which seem to serve several different purposes, so this will require some care.
- [ ] Remove the sleep calls in `InputStreamSuite`.  Most of these cases look simple to replace with the new StreamingTestWaiter, but the `testFileStream` case looks like it could be tricky.
- [ ] Investigate the uses in `ReceiverSuite`.  There are a few `Thread.sleep(0)` cases which seem confusing; if they're still necessary, they should be commented.
- [ ] Might be able to remove one or two low-hanging fruit calls in `MasterFailureTest`, since these seem to be blocking on events like the StreamingContext starting and we have waiters for this.
- [ ] Determine whether the fix for SPARK-4835 should be done differently (see discussion on JIRA).
This method is now misleadingly-named; it should be named something like `advanceTimeAndWaitForBatches`.  @tdas, was the intent here to wait for long enough that the batches actually finish?  Or did you ever want to use this for cases where we wait for the expected batch duration but see what happens when some batches take way longer?