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.
I think the `IgnoredPaths` object can help clean this up, too.