[FEATURE] Add `TimeSeriesSequence` collection type for more accessible multiple time series representation

[brunnedu]

Is your feature request related to a current problem? Please describe.
Working with multiple time series is central to many darts use cases. However the current list[TimeSeries] representation is opaque. Users cannot quickly discover what series they have (frequencies, lengths, date ranges), filter by metadata, or get a high-level summary like pd.DataFrame.describe(). Each TimeSeries carries static_covariates and metadata, but there is no collection-level API to query across them.

Describe proposed solution
Add a TimeSeriesSequence class: an immutable Sequence[TimeSeries] wrapper with collection-level convenience methods. It would implement collections.abc.Sequence, so it works everywhere list[TimeSeries] is accepted today (models, transformers, utilities) with no changes to existing call sites.

Desired Features:

• Construction: TimeSeriesSequence([...]), TimeSeriesSequence.from_group_dataframe(df, group_cols=...)
• Discovery: catalog (lazy one-row-per-series metadata DataFrame), describe() (summary statistics), info() (compact text summary)
• Filtering: filter(callable) — e.g. seq.filter(lambda ts: ts.n_timesteps > 100)
• Conversion: to_list(), to_dataframe() (wraps to_group_dataframe)
• Representation: repr and repr_html for terminal and Jupyter

Describe potential alternatives

• Stay with list[TimeSeries]: Manual loops and comprehensions for discovery and filtering.
• Use to_group_dataframe() as the query layer: Convert to DataFrame, filter/summarize, then reconstruct via from_group_dataframe(). Cumbersome and forces users to leave the TimeSeries abstraction.

Additional context

• The existing internal machinery (get_series_seq_type(), series2seq()) uses duck typing, not isinstance(ts, list), so TimeSeriesSequence inputs already work through models and transformers. No library changes required for acceptance.
• TimeSeries is immutable; making TimeSeriesSequence immutable follows the same philosophy.
• The lazy catalog avoids metadata extraction cost for users who only need indexing or iteration, while making describe() and filter() fast once materialized.

[JuanCruzC97]

Hi! I think this would be a great addition to Darts

I have a question regarding how this would interact with historical_forecasts outputs. As far as I understand, the current outputs can take different forms depending on the configuration:

• TimeSeries: single-series with last_points_only=True

• list[TimeSeries]:

  • single-series with last_points_only=False, or
  • multi-series with last_points_only=True

• list[list[TimeSeries]]: multi-series with last_points_only=False

With the introduction of TimeSeriesSequence, how would these output types evolve?

It would be especially helpful to have a way to easily identify how a given output was generated, particularly in the ambiguous case of list[TimeSeries], where it can correspond to two different scenarios (single-series vs. multi-series). Some form of explicit structure or metadata could make this much clearer for users.