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
Kind of. It addresses a bug. (a) I didn't know what `PG_GETARG_CSTRING` did (I thought it extracted a `char *` from a `text` arg; didn't know about the internal `cstring` arg type), and (b) I was misusing `strncmp`.