Validate schema before using it for resolution

[jml]

In #42, @teh and I both agreed that we should ideally not be checking for schema validity while we are resolving values.

The difficulty is that we need to construct values from the type-level schema in order to do the work of resolution.

The solution, as I see it, is to construct a value-level representation of the schema before resolving and to pass that as a parameter to buildResolver. As we traverse down the selection set that represents the user query, we would also traverse down the value-level schema, shucking off the top-most layer.

[jml]

Related, there's a TODO to switch from using the stand-in NonEmptyList to using the base library's NonEmpty, which actually enforces non-emptiness. I started on this, but am oh so tired and really need to get to work.

Probably the right way to do it is:

• [ ] Move Validator out of Validation into its own module, for common use
• [ ] Create a new SchemaError type in API.hs that includes the existing NameError
• [ ] Update type classes in API.hs to use Validator and SchemaError
• [ ] Update Resolver.hs for the new type classes
• [ ] Switch NonEmptyList to NonEmpty in Schema.hs
• [ ] Update API.hs to use NonEmpty
  • [ ] Extend SchemaError to have new branches for various empty lists
  • [ ] Throw these errors with throwE when the lists are empty

[jml]

Related, there are two TODOs for trying to enforce non-empty lists of fields etc. at the type level.

I'm pretty sure this is possible and even straightforward (although it will likely require more typeclasses).[*] However, I wouldn't want to begin to attempt it until the value-level stuff correctly enforced non-emptiness.

[*] If you can have a list of types, and you can have a product of types, then you can have a non-empty type. Fields Field [Field] would guarantee Fields is non-empty.