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.