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
Didn't want that complexity in the unit tests. That might sound odd, but parsing a fragment like that looked difficult, so I chose to build a fixed subset of clauses and test those.

Besides, I do have an `OR` test already (the `prune_using_either_value` test).