Update: Factor ignores out of Config

Fixes #958.

I thought that using the term "ignores" everywhere and never "exclusions" would make things more consistent and less confusing. The only confusing part now is where `isExcluded` is changed to `ignores.isIncluded`, but I think `ignores.isIncluded` makes sense by itself, it's just an odd difference. Open to suggestions.

All of the logic remains the same, but now instead of calling `Config.getExclusions` for an exclusions array and doing the matching logic in cli.js, you load up `Ignores` with a config object and then call `Ignores.isIncluded` which encapsulates the matching logic. (By the way, it's kind of confusing how the Config object is called "configHelper" in some places in cli.js.)
Okay, so you mean to cherry-pick both options into a new object, right? I asked about this earlier and the same question still applies:

> if we're already going to expose those options to the outer logic that is calling IgnoredPaths, why not just act on them at that point? That is, passing ignorePath to it as a direct parameter and not calling it at all if ignore is false.

My thinking is that if we're going to cherry-pick each option like so:

```
var options = {
    ignore: configHelper.ignore,
    ignorePath: configHelper.ignorePath
};
```

Then we're already exposing those values to the outer logic, so why not just simplify things and use them right away? It's fine either way, just a suggestion.