Rewrite of pg_dump TAP tests

Greetings,

Attached is a patch (which applies cleaning against a2a2205, but not so
much anymore, obviously, but I will fix after the releases) which
greatly improves the big pg_dump TAP tests.  There's probably more which
can be done, but I expect people will be much happier with this.  The
cliff-notes are:

Reworked how the tests are defined to instead of a set of 'full runs'
and then a way to exclude certain runs from certain tests (using the
same 'unlike' mechanism, but now it works to remove 'like' entries which
are pulled into the 'like' part by a broad hash).  This ends up removing
some 4k+ lines (more than half the file) but, more importantly, makes
the way the runs-to-be-tested are defined make more sense.

As discussed in the updated comments, for example, take the test which
does CREATE TABLE test_table.  That CREATE TABLE should show up in all
'full' runs of pg_dump, except those cases where 'test_table' is
excluded, of course, and that's exactly how the test gets defined now
(modulo a few other related cases, like where we dump only that table,
or we dump the schema it's in, or we exclude the schema it's in):

like => {
    %full_runs,
    %dump_test_schema_runs,
    only_dump_test_table    => 1,
    section_pre_data        => 1, },
unlike => {
    exclude_dump_test_schema => 1,
    exclude_test_table => 1, }, },

Next, we no longer expect every run to be listed for every test.  If a
run is listed in 'like' (directly or through a hash) then it's a 'like',
unless it's listed in 'unlike' in which case it's an 'unlike'.  If it
isn't listed in either, then it's considered an 'unlike' automatically.

Lastly, I've changed the code to no longer use like/unlike but rather to
use 'ok()' with 'diag()' which allows much more control over what gets
spit out to the screen.  Gone are the days of the entire dump being sent
to the console, now you'll just get a couple of lines for each failing
test which say the test that failed and the run that it failed on.  The
only concern I have with this is if it'll make analysis of buildfarm
failures difficult, but, thankfully, I've not seen too many cases of
pg_dump behavior differently in the buildfarm so perhaps this trade-off
for making it easier for hackers to work with will be worth the
reduction in clarity from the buildfarm in this specific case.

Comments and suggestions welcome, of course.  As mentioned, this applies
as of around a2a2205, but I will fix it either this weekend or early
next week to account for the recent changes.

Thanks!

Stephen