Breaking: CLIEngine abstraction for CLI operations

This PR is a first-pass at creating a mid-level programmatic API. This is intentionally not yet exposed publicly, as I'd like to test it in a release to catch bugs before encouraging developers to use it. Here's what the API looks like:

```js
var engine = new CLIEngine({
    configFile: null,    // -c
    reset: false,   // --reset
    rulePaths: [],   // --rulesdir
    useEslintrc: true,  // --eslintrc
    envs: [],   // -env
    globals: [],    // --global
    rules: {},    // --rule
    ignore: true,    // --ignore
    ignorePath: null    // --ignore-path
});

var output = engine.executeOnFiles(["file1.js", "files/"]);
// output.results is the full results as passed to a formatter
```

My intention is to add an `executeOnText()` method at some point in the future.

This API exists between the high-level `cli` and the low-level `eslint`. Some things to know:

* It doesn't do any console output at all, the `cli` object is solely responsible for that.
* The return value of `executeOnFiles()` is an object with one property, `results`, which is the results that are passed to the formatter. I intentionally did this to allow us to add more properties if we find we need them (people have asked, in the past, for number of files linted, ignored, etc.).
* It does do all of the file system input for you.
* The options names are different than those on the CLI options object mostly due to plural and disambiguation issues.
* All current CLI tests pass.
* I ended up removing the ability to pass a config into a formatter. I wanted to deprecate it first, but with this refactor, it became hard to continue passing that data along.
This test bothered me initially, with negations here and more on the ignore option itself where false is the non-default value. Unfortunately after digging through I haven't come up with a way to improve how it's handled before this that would be any improvement in clarity. However, applying De Morgan's law to this test in particular makes it slightly clearer to me personally: `if (!(this.options.ignore && isExcluded(filename, exclusions)) {` Do you agree, or is that just me? Negatives could be removed entirely by then swapping consequent/alternate bodies, but that would violate the convention of handling the primary case first, so again I'll leave it up to you to decide which option is clearer there.