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
Tautologically: because they do. If they ever fail to, something has changed in our code to cause hash values to go to different shards.

I don't know what kind of guarantees we make around consistency of hash values, but it's worth discussing. This test will break if the hash function outputs change.