language cleanups in code and docs

Hi,

We've removed the use of "slave" from most of the repo (one use
remained, included here), but we didn't do the same for master. In the
attached series I replaced most of the uses.

0001: tap tests: s/master/primary/
Pretty clear cut imo.

0002: code: s/master/primary/
This also includes a few minor other changes (s/in master/on the
primary/, a few 'the's added). Perhaps it'd be better to do those
separately?

0003: code: s/master/leader/
This feels pretty obvious. We've largely used the leader / worker
terminology, but there were a few uses of master left.

0004: code: s/master/$other/
This is most of the remaining uses of master in code. A number of
references to 'master' in the context of toast, a few uses of 'master
copy'. I guess some of these are a bit less clear cut.

0005: docs: s/master/primary/
These seem mostly pretty straightforward to me. The changes in
high-availability.sgml probably deserve the most attention.

0006: docs: s/master/root/
Here using root seems a lot better than master anyway (master seems
confusing in regard to inheritance scenarios). But perhaps parent
would be better? Went with root since it's about the topmost table.

0007: docs: s/master/supervisor/
I guess this could be a bit more contentious. Supervisor seems clearer
to me, but I can see why people would disagree. See also later point
about changes I have not done at this stage.

0008: docs: WIP multi-master rephrasing.
I like neither the new nor the old language much. I'd welcome input.

After this series there are only two widespread use of 'master' in the
tree.
1) 'postmaster'. As changing that would be somewhat invasive, the word
is a bit more ambiguous, and it's largely just internal, I've left
this alone for now. I personally would rather see this renamed as
supervisor, which'd imo actually would also be a lot more
descriptive. I'm willing to do the work, but only if there's at least
some agreement.
2) 'master' as a reference to the branch. Personally I be in favor of
changing the branch name, but it seems like it'd be better done as a
somewhat separate discussion to me, as it affects development
practices to some degree.

Greetings,

Andres Freund