feat!: refuse text values the browser physically prevents in TextFieldTester and TextAreaTester (#252) (CP: 25.3)

[vaadin-bot]

This PR cherry-picks changes from the original PR #252 to branch 25.3.

Original PR description

Summary

TextFieldTester.setValue and TextAreaTester.setValue used to accept values a real user could never type, such as text longer than maxLength or characters that allowedCharPattern blocks. They now refuse those values with an IllegalArgumentException, so a test cannot reach a state the browser would never produce.

Fixes #248

What changed

Breaking: setValue on TextFieldTester and TextAreaTester now throws IllegalArgumentException instead of committing the value when:

• the value is longer than maxLength (the browser truncates the extra characters), or
• the value contains a character that allowedCharPattern does not match (the browser filters out that keystroke).

This affects only tests that set such impossible values. Those tests used to pass with the value committed and the field left invalid; they now fail with an explanatory message. Note that a maxLength of 0 is treated as a real limit of zero, not as "no limit".

TextAreaTester.setValue(null) now fails with the same clear "Field doesn't allow null values" message that TextFieldTester already gave, instead of an opaque reflection wrapper around Flow's NullPointerException. Use clear() to empty a field.

Validation-only constraints are unchanged: minLength, pattern and required still commit the value and leave the field invalid, because that is what the browser does and what a validation test needs.

Internally, the shared checks moved into a new package-private TextInputConstraints class, so both testers use one copy. There are no public or protected API signature changes. Conventions and tester guidelines are updated to describe where the line falls.

Fixes #248

Test summary

• Values longer than maxLength and values containing characters blocked by allowedCharPattern are refused, and the field keeps its previous value.
• Values at the maxLength limit, and allowed characters, are still accepted.
• A maxLength of zero blocks any text, while emptying the field stays possible under any limit.
• An allowedCharPattern that is not a valid regular expression restricts nothing, matching the browser, which only logs a warning.
• Validation-only constraints (pattern, minLength, required) still commit the value and leave the field invalid.
• setValue(null) on a text area is refused.