Call rm_redo in a temporary memory context

Many resource managers set up a temporary memory context which is reset 
after replaying the record. It seems a bit silly for each rmgr to do 
that on their own, so I propose that we do it in a centralized fashion. 
The attached patch creates one new temporary context and switches to it 
for each rm_redo() call.

I was afraid of the overhead of the MemoryContextReset between each WAL 
record since this is a very hot codepath, but it doesn't seem to be 
noticeable. I used the attached scripts to benchmark it. 
redobench-setup.sh sets up a base backup and about 5 GB of WAL. The WAL 
consists of just tiny logical decoding messages, no real page 
modifications. The idea is that replaying that WAL should make any 
per-record overhead stand out as much as possible, since there's no real 
work to do. Use redobench.sh to perform the replay. I am not seeing any 
measurable difference this patch, so I think we're good. But if we 
needed to optimize, we could e.g. have an inlined fastpath version of 
MemoryContextReset for the common case that the context is empty, or 
only reset it every 100 records or something.

This leaves no built-in rmgrs with any rm_startup or rm_clenaup hooks. 
Extensions might still use them, and they seem like they might be 
useful, so I kept them.

There was no natural place to document this, so I added a brief 
explanation of rm_redo in the RmgrData comment, and then tacked the 
information about the memory context there too. I also added a note in 
"Custom WAL Resource Managers" section of the docs to point out that 
this changed in v18.

(Why am I doing this now? I was browsing through all the global 
variables for the multithreading work, and these "opCtx"s caught my eye. 
This is in no way critical for multithreading though.)

-- 
Heikki Linnakangas
Neon (https://neon.tech)