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.

I got the impression that it's stateful class that's responsible for running the test suite. But know you mention this, things makes more sense.

>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 libs -- vs pushing higher level CLI decisions down into the library.

Understandable. But in reality before I wrote this diff I had only glanced over the Facebook CLI  code and just wrote this to work with the package's CLI. And then when it came time to integrate it in FB it was rather easy (after understanding the CLI code). Just moving of things from if statements and method calls to the options. That's what I thought it boiled down to, leaving a lot of the decisions duplicated in CLIs or push them down to the TestRunner. I guess my object-oriented habits wanted to centralize those decisions and push them down into the class. Not going to lie, for me it makes it easier to reason about the code.

>That said, I think it makes a lot of sense for those helpers and methods to return a stream object rather than a Promise. 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).

Yeah that sounds like a better design decision.

>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)

Cool, that sounds good as well.