Validation for modules and graphs

[joshsh]

In defining a collection of Hydra source modules, there are a number of error scenarios which are currently avoided simply by sticking to best practices. However, in the future these best practices will need to be enforced. The following are a few of the error scenarios which could occur at the time when we build a graph out of list of modules, which we currently do not check for:

• Invalid term expression (including invalid type or term reference)
• Invalid type expression
• Type error / untypeable term, or inconsistency between inferred type and user-provided type
• Collision/duplication among any combination of {element name, namespace, primitive/UDF name} either within a module, or between modules
• Invalid names and/or namespaces (see #151)

Certain additional validation constraints may be needed in different contexts, and it should be possible to configure the set of rules which are enforced.

Doing validation early may have the added benefit of simplifying certain code (including everything otherwise requiring inference or lexical lookups). If a graph is known to be valid, then we could often use simpler, non-monadic code without error handling.

[joshsh]

Note: these validation modules can be organized into the new kernel namespacing scheme as hydra.validate.core, hydra.validate.module, etc. General-purpose helpers can go in hydra.validation.