Too wide (and falsy) segregation of GraphQL Types and Resolvers

The first example of this is new ObjectType in src/data/queries/index.js importing fields.
Fields should be taken in context of parent type, not as standalone information.

This can ensure some users that custom types cannot have own field resolvers which is false.

In fact, much of fields which can have own resolvers

• I've read the guidelines for Contributing to Roots Projects
• This request isn't a duplicate of an existing issue
• I've read the docs and followed them (if applicable)
• This is not a personal support request that should be posted on the [Roots Discourse](https://discourse.roots

#477 and a couple different #478 bugs stem from the expectation that setting prebuild: [] or postbuild: [] is a way of saying "prebuild: nothing" and "postbuild: nothing". In fact, the empty array creates problems (see the linked issues for examples)

This should at least be documented. Supporting [] as "nothing" would be an easy enhancement

I'd appreciate if there was a comparison of lite-server with http-server which is the most popular www dev server for node.js (according to npm, 3 times more downloads than lite).

• Explain setup and workflows with travis, tests, demo project, release, slack-channel, coveralls, david-dm, npm badges, tags ...
• Explain, review docs.

• compile styles - use #22 + styles task
• copy necessary files from theme directories (remember about inheritance)
• copy necessary files from /lib/web
• build require.js config
• copy and minify(?) html templates
• build js-translation.json

This could be useful for contributors to test any changes (manually for now) inside the repo, not having to use an external environment.
This folder should be in .npmignore.

Automated testing I think is out of the scope of this project since it's more of a wrapper plugin for Browsersync.
Perhaps some unit tests for the css emissions check?