Adding contexts and bug-fixes to editorconfig parsing.

@devoncarew - This addresses the comment on the last PR.  I'm doing it in a slightly different way than you suggested (by using Container and File contexts).  This allows the sections to not have to be re-filtered on every value retrieval.  I also fixed a couple of bugs and refactored the section parsing code into the constructor rather than a special method.

- Setup contexts for file and container to minimize the repeated passes on parsing and matching.
- Moved the initialization into constructor of context and provided a Future called whenReady rather than initializing in getSections()
- Fixed issue with chrome filesystem reporting two types of errors for no-file-found
- Fixed 2 bugs in Glob classes (incorrect end count causing missing slashes from regexes, and wrong matcher class for char-range pattern).
- Restored and fixed tests to use contexts.
- Added optimizations to Glob RegExps

Another pattern I've used - instead of `whenReady`, is to have a static ctor and a private instance ctor. So:
```
static Future<FooBar> createFooBar(...) {
  return someFuture.then((_) => new FooBar._(...));
}

FooBar._(...) { }
```
This has the benefit that, once created, the object is always ready to use. The clients of the object don't have to know about whether it's ready to use or not - only the person constructing it has to know about the async.