Tab completes a metric name, and an extractor name

[torstei]

graph <TAB> offered nothing. Reported from actually using 0.9.0.

Why the slot was empty rather than merely forgotten. The metric is typed
before from <source>, so at completion time there is no store to ask — which
is presumably why <metric> was left in offers()'s "anything, so offer
nothing" bucket alongside a count or a time.

But the extractor documents installed here declare the metric names, and
reading all of them costs 121 µs. So the slot now offers those:

timberfs=# graph <TAB>
app_duration  app_events  entries_logged  http_bytes  http_latency  http_requests

using and extracting get the same treatment from the same directories — they
take the file stems, which is what the lookup joins .json onto, not the
documents' own names, which can differ and would not resolve.

Both sides of graph Y against X are the same slot, so the scatter form
completes without a second entry in FORMS.

Two decisions worth stating.

⚠ It is a candidate set, not the truth. A tally store holds whatever metrics
the host that wrote it applied, which need not be what is installed locally — so
completion can miss a metric and can offer one the store lacks. A hint from the
documents beats the nothing that was there.

⚠ Not cached, deliberately. At 121 µs there is nothing to save, and the
workflow this exists for is writing a document and trying it from the shell — a
cache would mean restarting timbersh after editing your own extractor.

New in timbergraph.py: declared() (every document in the reading
directories, later shadowing earlier by filename, a half-written one skipped
rather than fatal), known_metrics() and known_extractors().

The test passes the directories rather than deriving them, patching
EXTRACTOR_DIRS — deriving them measures whether the timberfs package happens
to be installed on the runner, which is exactly the trap #174's Rust twin fell
into and #176 fixed.