proto: implement rich text editor impovements

[ugur-vaadin]

Description

This PR is a prototype for implementing the following for the RichTextEditor:

• basic validation including error message, required state as a constraint, and the required indicator
• label and helper text
• accessibility support for the features

Some notes:

• it should also support further constraints like minLength, maxLength etc as constraints
• lacks visual tests
• added styles break the borders in Lumo
• the baseline images seem to be 2 pixels shorter

Prototype for the improvements in https://github.com/vaadin/components-team-tasks/issues/631

Type of change

• Bugfix
• Feature
• Prototype

Checklist

• I have read the contribution guide: https://vaadin.com/docs/latest/contributing/pr
• I have added a description following the guideline.
• The issue is created in the corresponding repository and I have referenced it.
• I have added tests to ensure my change is effective and works as intended.
• New and existing tests are passing locally with my change.
• I have performed self-review and corrected misspellings.
• Enhancement / new feature was discussed in a corresponding GitHub issue and Acceptance Criteria were created.

[web-padawan]

Generally it's better not to rely on this element being present, as we changed it to use display: contents in the baseline alignment PR #10320. @jouni FYI, what should we do about this?

[jouni]

Yeah, I think I might leave out this wrapper element, and set the layout on the host.

[jouni]

One persisting thought I have about our field components is that instead of all of them individually reimplementing shared features (granted, via mixins), we would have a general-purpose "field" wrapper component, and then dedicated "editors" or "inputs" for various types (date, email, number, text, rich text, etc). I’ve explored that idea some years ago: https://jelements.netlify.app/prototypes/field/

Therefore, what I’d rather see, is that we don't add more features to Rich Text Editor, but consider implementing that general-purpose "field" component instead. And then maybe a "Rich Text Field" component for convenience. But that’s a bigger decision that needs broader discussion and agreement across the products (affects Flow as well).

[sonarqubecloud]

Quality Gate passed

Issues
10 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud