Add basic support for worktree branches (issue #629) - #633

A branch checked out somewhere else cannot be checked out here.

Closes the basic half of #629, independent of #630.

Two commits. The first fixes #635 - the ref label colors that had drifted into
two hard-coded palettes, and the current branch never reaching its orange in
the commit details pane. Both predate this work and can be reviewed on their
own. The second is the worktree support on top.

Worth knowing while reading the second: the #635 fix is also what makes the
worktree labels work, since a ref reaches the page through WebScripting as a
function and the class comparison had to be called through.

GitX showed such a branch like any other and then offered actions on it that
git refuses - or, in one case, that git does not refuse and should.

• Read git worktree list --porcelain and answer which worktree holds a given
  ref, our own excluded, re-read whenever the refs are reloaded
• Give those branches their own sidebar icon, a branch stem joined to a window,
  drawn on the same 16x16 grid as the icons beside it and kept in
  Resources/Images/Images.svg with the others; the row's tooltip names the
  worktree, since the icon says "held elsewhere" but not where
• Color their labels teal in both commit panes. colorForRef: switches on ref
  type, and a worktree branch is still type head, so those labels were plain
  green
• Offer "Open Worktree" in place of Checkout, its tooltip carrying the full
  path, and grey out Remove with a tooltip saying which worktree holds the
  branch - both settled while the menu is built rather than after the action
  fails. Remove stays in place rather than disappearing, so the entry does not
  go missing from under a reader who knows it should be there; a disabled item
  is built without its action, which is what keeps it from firing wherever the
  menu is shown.
• Refuse the removal in deleteRef: as well, so a caller that never asked
  cannot walk into it either

Why Remove matters more than Checkout

Checkout of such a branch is refused by git itself, so the cost of not knowing
was a confusing error (which #630 improves). Remove is different: GitX deletes
refs with update-ref -d, which has none of the safety git branch -d has.

$ git branch -D feature
error: cannot delete branch 'feature' used by worktree at '.../wt'

$ git update-ref -d refs/heads/feature     # what GitX runs
$ (exit 0, silent)

$ cd ../wt && git status
On branch feature
No commits yet

The other worktree is left on a branch that no longer exists. That is why the
check is in the repository as well as in the menu.

On the teal: the palette draws black text with no color set, so every existing
label color sits between 10.7:1 and 17.5:1 against it. #8fe0d5 is 13.8:1, and
at 36% saturation it sits between the green (42%) and the remote blue (32%)
rather than standing out from both.

Screenshots of Suggested Design

Local Branch - Show the Correct Colors (Bug-Fix 1)

Current Branch - Show the Correct Colors (Bug-Fix 2)

Worktree Branch - Show the New "Teal" Color and the New Icon

Worktree Branch - Show the New Context-Menu

• Can open a new GitX instance at the worktree's path
• Cannot delete the worktree's branch from here - we need to add support for that

Test plan

• make unit-test: 113 tests, 0 failures, 12 of them new, in
  PBGitRepositoryWorktreeTests (the porcelain reader over a main worktree, a
  linked one, a detached one, a locked one and a bare repository; our own
  branch excluded; the refusal to remove) and PBGitHistoryWorktreeMenuTests
  (Open Worktree replacing Checkout, Remove present but disabled and saying
  why, an ordinary branch unchanged)
• Confirmed the reader tests bite: with the reader returning nothing, 4 of them
  fail
• Checked in a Debug build against this repository, which has five worktrees of
  its own. Read back through accessibility, every branch another worktree holds
  carries WorktreeBranchTemplate, while master - held by this checkout -
  carries BranchTemplate plus the checkmark, and pr625, held nowhere,
  carries BranchTemplate alone. That matches git branch exactly, and it
  picked up a worktree added after the first run without being told.
• The commit list path was confirmed the same way: the teal branch runs for
  those refs and no others
• The icon and the two label colors were rendered offscreen to compare them at
  16x16 and magnified, in both tints
• The commit details pane was checked by reading its rendered DOM back out of
  the page: master [refs head currentBranch], a worktree branch
  [refs head worktree], a remote [refs remote]
• Not verified by eye in the running app: the tooltips (accessibility
  exposes no AXHelp for those rows) and the context menu itself, which does
  not survive an accessibility query - hence the unit test over
  menuItemsForRef:

Two things worth a look

The reader caches per refs-reload, and an early draw that finds no git binary
must not poison that cache with an empty answer - an earlier build did exactly
that, and no icon appeared until something forced a reload. It now returns empty
without caching, so the next draw retries.

The first lookup after each reload shells out to git inside a draw pass on the
main thread. That is the shape the sidebar already had, one subprocess per
reload, but the commit list reaches for it too now.

Not in scope: creating or removing worktrees, and a WORKTREES section in the
sidebar next to SUBMODULES.