clipboard: reach the primary (middle-click) selection (#67)

[changkun]

X11 and Wayland have two clipboards. CLIPBOARD is the Ctrl+C one; PRIMARY
holds whatever was last selected with the mouse and is pasted with the middle
button, and they are independent — copying does not change the selection. This
package only ever touched CLIPBOARD (the atom was hardcoded at three call
sites), so a clipboard manager built on it silently missed half of what a Linux
user does.

API

You picked options on the existing calls, and then the Format-implements-
Option resolution for the variadic clash:

type Option interface{ apply(*config) }

func FromPrimary() Option

sel := clipboard.Read(clipboard.FmtText, clipboard.FromPrimary())
ch  := clipboard.Watch(ctx, clipboard.FmtText, clipboard.FromPrimary())

Format and Item implementing Option is load-bearing, not decoration:
Watch and WriteAll had already spent their variadic slot, and Go allows only
one, so opts ...Option could not have been added to them at all. One
variadic slot now carries both what an operation acts on and how — and every
existing call site keeps compiling, which matters because Read, Write and
Watch have been public since v0.1. TestOptionsAreSourceCompatible pins that.

WriteFiles changed shape: (paths ...string) → (paths []string, opts ...Option). A string cannot implement Option without swallowing every stray
string argument. It shipped in #152 an hour ago and is in no tag, so nothing
depends on the old form — but it is a real signature change and worth a look.

Per backend

Backend	Mechanism
X11, BSD	PRIMARY instead of CLIPBOARD as the selection atom. Ownership, TARGETS and the serve loop are untouched — selections are a general mechanism there and CLIPBOARD is just one atom.
Wayland	set_primary_selection / the primary_selection event. Needed the data-control manager bound at version 2 instead of the hardcoded 1; below that it reports unsupported without disturbing the ordinary clipboard.
Windows, macOS, mobile, CGO-disabled	No second clipboard: read returns nil, write is refused.

Refusing the write is the point. Redirecting it to the ordinary clipboard would
silently destroy whatever the user had copied, so
TestPrimarySelectionDegradesSafely asserts exactly that — and that a watch
which can never fire closes rather than leaving the caller waiting forever.

One thing worth reviewing closely

The selection is threaded through the backend entry points as an argument,
not read from a global, so a FromPrimary read cannot race a normal one. That
meant renaming two Wayland locals that would otherwise have shadowed it:
selection → current, and a closure's sel → offerID. Worth the churn — a
shadowed selection argument inside a loop that dispatches on selection opcodes
is precisely the bug that hands back the other clipboard's data while every
same-process test still passes.

Design notes in specs/primary-selection.md.

Tests

• TestPrimarySelectionIsIndependent — the one that fails without this: write
  different content to each, read both back. Before, the second write landed on
  the same clipboard and the first value was gone, so it fails on both halves.
• TestPrimarySelectionEnumerates / TestPrimarySelectionWatch — enumeration
  and watching are separate paths on every backend, asserted against a selection
  the other clipboard does not hold.
• TestPrimarySelectionDegradesSafely — the platforms without a second
  clipboard, per above.
• TestWaylandPrimarySelection — cross-process via wl-paste --primary. The two
  selections are set by different requests and announced by different events, so
  confusing them would look like success to any same-process test.

Verified locally on darwin (the degradation half). X11 and Wayland are covered
by CI; the Wayland test skips if sway's data-control manager predates v2.

Fixes #67