WIP: Rework the way multixact truncations work.

WIP: Rework the way multixact truncations work.

The fact that multixact truncations are not WAL logged has caused a fair
share of problems. Amongst others it requires to do computations during
recovery while the database is not in a consistent state, delaying
truncations till checkpoints, and it handling members being truncated,
but offset not.

We tried to put bandaids on lots of these issues over the last few
years, but it seems time to change course. Thus this patch introduces
WAL logging, even in the back branches.

This allows:
1) to perform the truncation directly during VACUUM, instead of delaying it
   to the checkpoint.
2) to avoid looking at the offsets SLRU for truncation during recovery,
   we can just use the master's values.
3) simplify a fair amount of logic to keep in memory limits straight

During the course of fixing this a bunch of bugs had to be fixed:

1) Data was not purged from memory the member's slru before deleting
   segments. This happend to be hard or impossible to hit due to the
   interlock between checkpoints and truncation.

2) find_multixact_start() relied on SimpleLruDoesPhysicalPageExist - but
   that doesn't work for offsets that haven't yet been flushed to
   disk. Flush out before running to fix. Not pretty.

WIP COMMIT MESSAGE