ShmemIndexLock rewrite

Here is a proposed patch pursuant to the idea of turning ShmemIndexLock
into an LWLock instead of a spinlock, as discussed last week. I remember
now that we tried to do that before, and found out it was a pain in the
neck :-(. The problem is that you can't use LWLocks until you have a
PGPROC, and in the existing code backends don't acquire a PGPROC until
down inside InitPostgres. So some rearrangement of the startup sequence
is needed to make this work.

What I've done in the attached patch is to split InitProcess into two
parts, one that just creates a PGPROC (and is actually pretty comparable
to InitDummyProcess) and one that inserts the PGPROC into the shared
ProcArray. So a backend that has done just the first part is in a state
comparable to the way that dummy processes run for their entire existence:
it has a PGPROC but is not a member of ProcArray or the sinval ring.
This means it can grab LWLocks, but can't run transactions.

InitProcessPhase2 is still called from the same place in InitPostgres,
but InitProcess is moved elsewhere: in the ExecBackend case it's done
in SubPostmasterMain before calling CreateSharedMemoryAndSemaphores,
and otherwise it's done wherever convenient.

I found I also had to move the on_exit_reset calls, because that has to
happen before InitProcess, else we lose the shutdown callback that it
has to install for releasing the PGPROC.

Lastly, I split BackendRun into two parts, so that SubPostmasterMain
could perform client authentication before it runs InitProcess. This
avoids holding a PGPROC before we know the client is legit. (I could
alternatively have put the InitProcess call into the middle of
BackendRun, but this seemed cleaner.)

One advantage of doing this is that autovac is able to acquire its PGPROC
before it does the work of deciding which database to attach to. This has
no immediate use but it might allow future improvements, such as
inspecting the free space map while deciding which database to look at.

But other than that, this is kind of ugly :-(. Any opinions whether to
apply it, or leave things as they are?

regards, tom lane