Revert "Try always committing deltas on 8.4 and higher."

This reverts commit 964ac9b960bf85fe7bf01d0ece9f944170f20703.
Test makedelta vs non-makedelta.

By adding another test table with makedelta=off. Also, make sure that there
are not duplicate/multiple syncdone messages, as they would indicate circulare
replication patterns (as were present in 964ac9b and removed in 9e7227e).
Resolves #19.
Use arrays.
First stab at getting makedelta working again.

Add code to push_rows() that inserts the proper delta and track records if the
target is PostgreSQL. Tests fail just as before because nothing tickles the
autokick, which is disabled by the replication KID. There is a NOTIFY for a
makedelta job, though, so perhaps that can be used?
Let's make table-level makedelta an open field for future ideas.
Let's make the triggerkick triggers always: this should solve one of the makedelta issues.
No longer need to worry about explicit kick after makedelta
This is not the place to update track
This is where the makedelta track update happens.
For makedelta, we need to set it as on/off per table inside each database. We do this via the is_makedelta attribute. If this is set, we can walk through at the end and force a track/stage update as needed, in the case where we had no delta changes on the makedelta table in question, but some other database did - which means that it put some new rows inside our delta table. Note that we don't need to explicitly update the track table, as the normal insert/update/where not exists SQL handles this case just fine.
Still to do: populate is_makedelta, based on what is in goat.makedelta and possibly also db.makedelta.
Placeholder for populating is_makedelta
More makedelta work, write out some ideas.
Better makedelta work: this should allow things to work mostly as intended now.
For the makedelta system, we'll store everything at the goat/table level: the new value is a list of databases. Remove makedelta from the db table, as it is no longer needed.
Restore listen for syncdone_deltatest2.

It is now triggered properly.
Get `makedelta` tests passing.

Requires two things:

1. Restore the insert into the track table that was removed in d2d2cbd1d2.
   Otherwise, when the autokick kicks off the sync after the sync from A to B,
   the data is synced back to A. Then back to B, and on and on.
2. Modify `wait_for_notice()` to handle a list of notices to wait for. This is
   beause the syncdone message can be sent in random order, so we were getting
   failures by listening for one and then another. So we allow an array
   reference of notices to be passed, and it will wait for them all.
Add a double-multi-master replication makedelta test.

Consider this:

* You have two databases, A and B, with multi-master replication between all
  of their tables.
* You have a third database, C that needs to be the target of replication for
  just one of those tables, "widgets".
* If A goes down, C stil needs the widgets updated on B.

Solution:

* Add a relgroup with just "widgets"
* Enalbe "makedelta" on "widgets"
* Add a dbgroup with A:source, B:source, C:target
* Create a sync with that dbgroup and the widgets-only relgroup.

This is effectively the case these new tests demonstrate. However, it means
that there are *two* multi-master replication syncs between A and B for the
"widgets" table. This is a bit of a drag, as it means that everything will be
synced twice.

But not only that, if A goes down, will the sync with C as the target succeed
or fail?
Did not mean to commit that.