WIP: deferred-trigger rewrite

Since this is a rather larger patch than we customarily apply during
beta, I thought I'd better circulate it for review before pushing it in.

It is not ready to apply yet because it lacks regression tests or doc
updates, and also I haven't yet done anything about the idea of saving
space by sharing information across many firings of the same trigger.
But it addresses the basic problem of firing AFTER triggers at the
"right times" within functions. And I think it offers a reasonable
approach to the issues Stephan raised about what happens when a trigger
function mucks with the firing order by executing SET CONSTRAINTS.
In this implementation, any particular query determines the set of
pending triggers it will fire before any of them are actually executed.
A SET CONSTRAINTS within one of those triggers cannot alter the
scheduling of any already-scheduled-to-fire trigger, but it can enable
and execute triggers that the outer query has determined it will not
fire.

I also took the liberty of renaming structs and functions in the
interests of clarity. In particular, all the "DeferredTrigger" stuff is
now "AfterTrigger" stuff, since it actually handles all AFTER triggers
whether they are "deferred" in the spec's sense or not.

Comments, objections, better ideas? I hope to commit this in the next
couple days.

regards, tom lane