[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 usage of `SystemClock` was a little tricky to fix.  It looks like the reason that this test used `Thread.sleep()` was that `FileInputDStream` relied on the filesystem timestamps matching the system clock when determining whether files were new.  Instead, we can just manually those files' modification times.  I had to spend a bit of time fiddling with the actual constants used in this test, so it would be great if someone could take a look to make sure I haven't inadvertently broken the test's ability to catch bugs (might be good to whiteboard out a reasonable set of constants in terms of batchInterval, window size, etc).