New schema generation pipeline

Right now, schema generation pipeline works in this way:
- collect metadata from decorators (options, reflected type, placement (method/field, name, class)
- put them in raw shape in `MetadataStorage`
- "build" the metadata (by modifying `MetadataStorage`)
- attach fields to types definition
- attach args to resolvers definition
- attach other metadata (middlewares, roles, etc.)
- doing it sequentially, metadata type by type (fields, then handlers, etc.)
- generate the schema with `graphql-js` using "built" metadata from `MetadataStorage`
- check for inheritance and interface implementing, then copy it's definitions
- handle all overloading and overwriting cases

It wasn't designed for such complicated features as inheritance, etc., so it has started to became a bottleneck. So the schema generation pipeline has to be rewritten into a new design:
- `MetadataStorage` store all small parts of metadata from decorators (like now)
- `MetadataBuilder` takes `resolvers` and `types` to build the extended, full metadata
- not modifying `MetadataStorage`, working like a "pure" function
- doing it on demand (not all the types in one time but lazily, step by step, recursive and with caching)
- attaching all loose metadata to the base metadata definition
- handling all extending, implementing and overwrtiting cases
- `SchemaGenerator` accepts built metadata object and generate schema corresponding to the metadata (without need for checking the metadata storage)

This would simplify this pipeline a lot, as well as allow to implement new features and allow to fix #133 and #110.