Support JSON Schema in Config 

JSON Schema ([schema core](http://json-schema.org/latest/json-schema-core.html), and the [supported keys](http://json-schema.org/latest/json-schema-validation.html))

It will look like this:

```coffee
@config:
  fontSize:
    type: 'integer'
    default: 16
  lineHeight:
    type: 'number'
    default: 1.3
  someArray:
    type: 'array'
    default: ['ok', 'yeah']
    items:
      type: 'string'
  invisibles:
    type: 'object'
    properties:
      eol:
        type: 'string'
        default: '\u00ac'
      space:
        type: 'string'
        default: '\u00b7'
```

### Notes

* If a value is passed to `::set` cannot be coerced, it will not be set (eg. passing `'omg'` to an integer type)

### TODO

* [x] support some of the fancy bits of the schema (minimum, maximum, enum)
* [x] deprecate the `getInt` style methods
* [x] use in our internal classes
* [x] read schema from loaded packages
* [x] figure out a reasonable notification when there are issues loading user's config
* [x] deprecate `configDefaults`
* [x] write a doc about it I can point to
* [x] write good docs into Config class
* [x] Move config schemas out of workspace and editor
* [x] convert a package to use schema in a PR https://github.com/atom/git-diff/pull/40
* [x] make sure settings view works
On the topic of `_.clone` it is necessary as it's munging with the specs. Here's how it effs up:

With no clone, it extends the object on this line onto the `Config::schema` object. This is shallow, so it just uses the object in properties:

```coffee
schema:
  type: 'object'
  properties: {} # <- this is the object from the import
```

Now, when specs create a new top level key, they are jamming it into that shared object from the export. The same thing would happen too if we were to add new editor config keys, as the clone is shallow as well. Ideally this would be a deep clone, but `_` has none.