Extend builder and write initial checker

[njgheorghita]

What was wrong?

• added pin_sources() and inline_sources fns to builder, to allow for creating a pinner/inliner from which you can pin/inline multiple sources
• added init_manifest() to builder for simpler init-ing
• started writing the checker tool

How was it fixed?

Cute Animal Picture

[njgheorghita]

@pipermerriam started writing the checker, for a manifest. How specific should these checks be? Now that i'm typing out loud, how about as specific as possible, but ignoring any type-checking? The assumption being that the checker raises warnings according to the natural language spec and would be used in tandem with validate() (which does any type-checking against the json-spec).

Any thoughts on the general direction/api of the checker would be great

Also, i'm not sure we can follow the pinner/inliner pattern for contract sources. Since there are so many optional args, our only options that I could tell would be to either provide each contract_type() individually with it's associated compiler_output - or you can curry together an "extractor", but in that case the user has to explicitly provide all the bool args. i.e

extractor("Owned", abi=False, natspec=True, deployment_bytecode=False, runtime_bytecode=False, compiler=True ...)

[njgheorghita]

Yeah, i'm not the biggest fan of those tests, and their coverage isn't as great as I'd like. But, like you said, I was hardpressed to come up with a better way that would be worth the time to implement. When I get around to extending the checker, i'll give it another go