Add filter panel columns without color layouts

[afloresep]

Fixes #29.

The problem

The only way to get a column into the filter panel was add_color_layout,
which also picks a colormap for it. If you only wanted to filter on a column,
you paid for colors you were never going to use.

The fix

viz.add_filter("MW", props["mw"].tolist())
viz.add_filter("Ring Count", props["n_rings"].tolist(), categorical=True)

The column is packed exactly the way a color layout is, so the panel behaves
the same: a slider for numbers, one clickable bar per group for categories.
What it skips is the color work, and it stays out of the color selector.

Color layouts can already be filtered on, so add_filter columns go into the
panel on top of them rather than instead of them. Setting filterable by hand
still replaces the lot:

viz.filterable = ["MW", "LogP"]   # exactly these, nothing else

add_as_label=False keeps a filter column out of the hover tooltip.

Calling add_filter on a name that is already a color layout raises, since
that column can already be filtered on and overwriting it would lose its
colors.

What changed

• TmapViz.add_filter, plus a filter / filter+label column role.
• The numeric checks in add_color_layout moved into a shared helper, so both
  methods reject text in a numeric column the same way.
• The panel itself needed no JavaScript changes. It reads metadata.filters
  and fetches whatever that names.
• One template change: the neighbour comparison strip picked its numbers from
  the color layouts alone, so it came up empty on a map built only with
  add_filter. It now draws from the filter panel and the color layouts
  together.
• docs/visualization_guide.md and docs/api_reference.md.

Tests

12 new tests: the column is registered but is not a layout, no colormap is
produced for it, categorical and numeric packing, add_as_label, the error on
a name that is already a layout, panel ordering, filterable still winning,
and the comparison strip falling back to the filter columns.