Add responsive DataTable feature with configurable breakpoints

[alexandre-castelain]

Summary

This PR adds opt-in responsive support to data tables, letting columns collapse a configurable breakpoint instead of being rendered at every viewport.
The goal is to make tables usable on narrow viewports without consumers having write custom CSS or duplicate column configurations.

Motivation

Data tables render poorly on small viewports when they contain many columns.
Today, consumers have to either hide columns via external CSS (brittle) or maintain per-device column configurations by hand. A first-class breakpoint inside the bundle solves this once, in a way that integrates with the column priority / visibility / personalization features.

Design

• Breakpoints are configurable, not hard-coded to a device enum. Default values follow Bootstrap conventions (sm: 576, md: 768, lg: 992, xl: 1200) but can be overridden globally or per DataTableType.
• The viewport width is measured on the client (Stimulus controller with ResizeObserver) and sent as a raw pixel value. PHP then resolves the breakpoint via BreakpointResolver`. This means a table displayed in a sidebar and one displayed full-width can resolve different breakpoints on the same screen.
• UserAgentDeviceDetector provides a server-side fallback (for the initial render, before JS measures the viewport) based on estimated widths.
• Column option visible_from: 'md' (string | false | null) controls the minimum breakpoint at which a column is rendered.
• Opt-in: the feature is gated by a responsive_enabled global flag and per-table override. Existing tables are unaffected.
• Theming: ships two dedicated themes (bootstrap_5_responsive.html.twig, tabler_responsive.html.twig) and a _responsive.html.twig partial for reuse in custom themes.

Backwards compatibility

No breaking changes. The feature is opt-in: responsive_enabled defaults to false and existing DataTableTypes behave exactly as before.

Open questions for maintainers

1. Scope check — does a first-class breakpoint system align with where you want to take the bundle, or would you prefer it as a separate bridge package? Happy to adjust either way.
2. Naming — visible_from vs. breakpoint vs. something else for the column option? I picked visible_from for symmetry with the existing visible option, but open to whatever matches your conventions.
3. Default breakpoints — I used Bootstrap's sm/md/lg/xl. Would you prefer unitless / framework-agnostic names, or keep Bootstrap aliases since one of the built-in themes already targets Bootstrap 5?

Thanks for the bundle — happy to iterate on review.