apollo-compiler 1.0 checklist

[lrlna]

### Potential breaking API changes (to do before leaving beta, or decide not to do)
- [ ] https://github.com/apollographql/apollo-rs/issues/708
- [ ] https://github.com/apollographql/apollo-rs/issues/709
- [ ] https://github.com/apollographql/apollo-rs/issues/710
- [ ] https://github.com/apollographql/apollo-rs/issues/711
- [ ] https://github.com/apollographql/apollo-rs/issues/538

### Tasks
- [x] validation on top of current data structure
- [x] port the router to the new APIs
- [x] set_type_system_hir
- [x] run on the schema corpus
- [x] remove `hir` module
- [x] adding to the test suite with old `hir` to test the new `hir`
- [x] finish porting validation code to compiler-less mechanism
- [ ] docs for the new architecture
- [ ] docs for new API usage (rust inline docs + readme)
- [ ] add performance benchmarking between new vs old vs graphql-js implementation (validation specifically)
- [ ] example: operation manipulations
- [ ] example: synthetic/logic based schema creation (only merge specific fields in an object type)

[SimonSapin]

set_type_system_hir

Similarly, users may want to validate a programatically-created ExecutableDocument without serializing and re-parsing it. So we’d need a naming scheme for all four combinations of adding input to a compiler, on two axes:

• A string to be parsed v.s. a high-level data structure
• Schema v.s. executable

(Plus one for a mixed schema-and-executable string to be parsed, though there’s no data structure equivalent)