Reverse the search order in afterTriggerAddEvent().

Reverse the search order in afterTriggerAddEvent().

When scanning existing AfterTriggerSharedData records in search
of a match to the event being queued, we were examining the
records from oldest to newest.  But it makes more sense to do
the opposite.  The newest record is likely to be from the current
query, while the oldest is likely to be from some previous command
in the same transaction, which will likely have different details.

There aren't expected to be very many active AfterTriggerSharedData
records at once, so that this change is unlikely to make any
spectacular difference.  Still, having added a nontrivially-expensive
bms_equal call to this loop yesterday, I feel a need to shave cycles
where possible.

Discussion: https://postgr.es/m/4166712.1737583961@sss.pgh.pa.us