Fix - Table question column validation

[RomainLvr]

Checklist before requesting a review

Please delete options that are not relevant.

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• I have updated the CHANGELOG with a short functional description of the fix or new feature.
• This change requires a documentation update.

Description

• It fixes !43740 & Fixes the unfinished work on Feat - Add configurable table question type #31
• Here is a brief description of what this PR does

Problems

• A column's pattern could be applied to another column: with a pattern on columns 0 and 2, column 1 inherited column 2's pattern and column 2 lost its check. This is the reported bug by the customer.
• Patterns that were not anchored at both ends, or carried a flag such as /…/i, rejected values they should accept.
• Setting a pattern on a typed column silenced that type's own format check, so an e-mail column with a pattern stopped validating e-mail addresses.
• Server-side errors were repeated once per cell.
• Row bounds were handled by a mechanism specific to this plugin, and were never actually checked on submission.

Fixes

• The required columns and patterns sent to the browser are now built in PHP, from the same rules the server validates against, and keyed like the submitted field names. They were built in Twig with the merge filter, which renumbers integer keys and shifted a pattern onto the neighbouring column.
• The HTML pattern attribute is no longer emitted. It is implicitly anchored and ignores flags, so it disagreed with both the PHP and the JS check.
• Matching is delegated to GLPI's RegexConditionHandler, and each column's question type keeps its own format check.
• Server-side errors are gathered into a single list below the table.
• Min rows / Max rows are replaced by a native condition criterion on the number of filled rows.

Breaking change

The Min rows / Max rows settings are removed. The row count is now a native criterion, usable for validation (Length is greater than…) and for visibility.
Bounds configured in 1.2.0 are ignored and must be redeclared as validation conditions on the question.

[Rom1-B]

This cleanup also removes messages already relocated into #errors, since they keep the invalid-tooltip class and #errors sits inside table. Resubmitting without fixing anything briefly wipes the message.

Suggested change

	table.querySelectorAll('.invalid-tooltip').forEach(el => el.remove());
	// Clears core's stale server errors before a blocked resubmit; skip the
	// ones already relocated below the table so they survive.
	table.querySelectorAll('.invalid-tooltip').forEach(el => {
	if (!el.closest('[data-af-table-errors]')) { el.remove(); }
	});

[Rom1-B]

Changelog only lists the bug fix; the breaking Min rows/Max rows removal and its mandatory-question caveat aren't documented.

Suggested change

	### Changed
	- **Breaking**: `Min rows`/`Max rows` removed; use a `Length is greater/less than...` validation condition instead (also mark the question mandatory to enforce a minimum, since an empty table skips validation)