Re: 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.