Implement watching

* Implemented watching option in the TestRunner class.
* Added watching option to the bin.

The way this feature works is that it runs all tests on the first run when `--watch` is passed and then idles while watching the `testPathDirs` and when something has changed, deleted, or added, tests will be run that relates to the changed file (or dir).

I implemented this in `TestRunner` to be able to reuse it internally. And by doing so I had to move a lot of the file pattern matching logic into the class. But I think it's seems like it belonged there anyways.

closes #38 #7

cc @benjamn @jeffmo @tomocchino
Hmm, right now TestRunner is structured as a library utility for various methods one might need to implement a CLI.
This is intentionally kept separate from the cli JS to support the ability to build custom CLI scripts as needed (for example, we use a custom CLI at Facebook -- but all of the common operations like finding files given a pattern, running tests in parallel/in-band, etc are just methods on the TestRunner object). The only reason TestRunner isn't just a bag of utility functions (i.e. the reason it's a class) is because all of the util functions depend on stuff from the `config` object. I'd like to keep this pattern because it will make it easier to write custom uses of the Jest internal -- rather than pushing all higher level CLI operations down into the library.

That said, I think it makes a lot of sense for those helpers and methods to return a stream object rather than a Promise<Array>. I had started to refactor TestRunner to do this before, but didn't quite finish. It turns out we can squeeze other bits of perf out of doing this as well (but that's kind of a separate topic).

So rather than pushing interface-level decisions like "should I watch? or should I run on changed paths? (etc)" into `TestRunner`, it would be nice if we could just add another method to TestRunner that streams changed files back out to the CLI. That way CLIs can decide how they want to handle those events (maybe some CLIs may want to do some pre- or post-processing before running a test? Or report back to a logger? etc)