Add comprehensive unit/integration tests

My methodology here is to expose each file's `extern` functions through some sort of SQL-visible function such that it becomes possible to test each piece of `pg_shard`'s functionality in a fairly modular fashion.

Where this was burdensome, (planner/executor), end-to-end integration tests were added instead.

Certain SQL features (`WINDOW` functions, etc.) still lack tests, but `pg_shard`'s coverage is vastly improved by these changes.

We continue to use `$PGPORT` to interpolate port numbers into tests (just a few `sed` commands), but have added a launcher wrapper to move any pg_worker_list file aside during test in order to substitue a known file to exercise everything we need during the tests.

I think long-term, we will want to look at something like [cmocka][] to help write actual unit tests. Integration tests should be performed in an actual test-only cluster built by our build logic, as opposed to the usuall `make installcheck` practice of building against the user's DB. But we'll consider that when and if we outgrow this.

Resolves #23.

[cmocka]: http://cmocka.org
No `master_create_distributed_table` is a level of logic on top of `InsertHashPartitionRow`. It assumes a correct `InsertHashPartitionRow` already exists for its use. Properly speaking, a unit test of `master_create_distributed_table` would mock out the underlying function call rather than actually calling it. In this way, a failing unit test would correctly show which part is broken.

If you test the metadata functionality by calling the functions that call it, a failing test isn't specific: it won't tell you whether the underlying metadata functions or the higher-level logic using them are the problem. By testing each in isolation we have better specificity.