Support LowCardinality identifiers in the TimeSeries table engine - #117033

…ric selectors

With id narrowing the narrowed id set filters the rows exactly, so the
whole-metric primary-key range conditions are index-analysis-only:
wrap them in indexHint, and the runtime filter then reads only the
second-component subcolumn of the id (the first component is not read
at all). For other narrowed selectors the full-shaped id set filters
the raw id column, which is therefore read anyway: disable the
tupleElement-to-subcolumn rewrite there so the second component is
extracted from the read column instead of being read from disk twice.

Measured on 128M samples (8 metrics x 800 series x 20k samples,
single part, warm): whole-metric scan 63 ms -> 44 ms, range rate
queries 113-117 ms -> 93-97 ms vs the plain Tuple(UInt64, UUID) id.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- Configuration::id_data_type is now simply the type of the id column
  returned by timeSeriesSelector (the second component's type when the
  id is narrowed), so the table function returns it as is; the type of
  the TimeSeries table's own id column moved to table_id_data_type.
- Replace the narrow_id_to_second_component/return_first_component_too
  parameter pair of makeSelectQueryFromTagsTable with the
  TagsSubqueryIDForm enum describing what the tags subquery returns as
  the series identifier.
- makeSelectQueryFromDataTable takes the ready-made id SELECT-list
  expression instead of a narrowing-specific flag.
- Explain why the narrowed id set is used only together with the
  whole-metric range conditions: a set of second components cannot
  constrain a prefix of the sorting key (id, timestamp), and giving
  every selector a second, index-analysis-only set would cost a second
  tags-table scan per selector.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ke plain ones

Per review: remove the id-narrowing machinery from timeSeriesSelector
(the second-component SELECT rewrite, TagsSubqueryIDForm, the indexHint
wrapping of the range conditions and the subcolumns-rewrite tweak).
A LowCardinality id now goes through exactly the same query shapes as a
plain one; what remains of the feature is:

- the default id generator supports LowCardinality-wrapped component
  types (the hash is dictionary-encoded in the generated expression);
- the whole-metric primary-key range conditions are emitted for
  LowCardinality id components too;
- ContextTimeSeriesTagsCollector::getGroupByID/getTagsByID process
  LowCardinality id columns per dictionary key, resolving lazily only
  the keys referenced by some row (a shared dictionary can contain
  identifiers whose rows were all filtered out and which are therefore
  unknown to the collector), and timeSeriesIdToGroup/timeSeriesIdToTags
  opt out of the default LowCardinality implementation for the same
  reason.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…nality-id

# Conflicts:
#	src/Interpreters/ContextTimeSeriesTagsCollector.cpp
#	src/Interpreters/ContextTimeSeriesTagsCollector.h
#	tests/queries/0_stateless/04600_timeseries_column_validation.reference