Add a Forms\TextArea component with label, value, and warning associations #45

Summary

Add a dedicated multiline text component alongside Forms\TextInput. The current public src/Forms/ directory has no textarea component, so consumers must compose its label, value, and warning associations themselves.

Proposed API

Illustrative API, matching existing component conventions:

use Eightfold\HtmlBuilder\Forms\TextArea;

TextArea::create('Notes', 'notes', "First line\nSecond line", 'Add more detail.')
    ->inputProps('rows 4', 'required required')
    ->labelProps('class notes-label');

create($label, $name, $value = '', $warningMessage = '') could accept the same label/name and warning types as TextInput. inputProps() targets the textarea; labelProps() targets its label.

Possible implementation

Compose HtmlBuilder elements: a label whose for matches the textarea's id, a textarea with matching name, and optional warning markup carrying {name}-warning. With a warning, set aria-invalid="true" and associate it through aria-describedby, preserving any existing help IDs.

Unlike an input, the value belongs in element text, not a value attribute. Define the encoding contract explicitly: raw multiline text versus caller-encoded content must not be ambiguous, and text must be encoded exactly once. Preserve whitespace rather than trimming or normalizing it. HTML ignores one leading newline immediately after a textarea start tag; the renderer must account for that if it promises round-trip preservation of leading newlines (for example, prepend one parser-consumed newline before encoded content).

Keep session stores, posted-value precedence, application validation, and CSS policy outside this generic component. No JavaScript should be needed.

Acceptance coverage

• Label/control and warning/control associations; no warning attributes when absent.
• Empty and populated values; leading, internal, and trailing newlines.
• Text containing </textarea>, <script>, ampersands, and quotes cannot escape into executable markup; no double encoding under the documented contract.
• Native rows, required, readonly, and disabled attributes.
• Existing help references survive addition of a warning.
• Plain-string and PropertyInterface warning forms follow existing conventions without duplicate warning nodes.