fix(widgets): declare TextArea's inherited trim config unsupported

[nebojsa-peric]

Implements option 2 from #1320.

TextArea substitutes its own Input, which commits the raw value, so the inherited trim never applied — while the type surface and docs advertised it.

• TextAreaConfig extends Omit<TextFieldConfig, "trim"> — <TextArea trim /> is now a compile error instead of a silent no-op.
• TextArea.prototype.trim = false — a global TextField.prototype.trim = true no longer leaks in (it would otherwise still compute an unread data.trim).
• trim: false in the docs config, alongside the existing icon/showClear/hideClear/inputType.

Behavior is unchanged: whitespace is preserved exactly as before. Note that the knock-on effect in #1320 — a whitespace-only TextArea passing required — is inherent to option 2, not fixed by it. validateRequired reads state.empty, derived from the raw input value.

Related finding, not fixed here

trim isn't alone. icon, showClear, hideClear, alwaysShowClear and inputType are in the same state: disabled in the docs config, absent from TextArea.tsx, inert at runtime — but still accepted by the type. All of these compile clean today and do nothing:

<TextArea icon="search" />
<TextArea showClear />
<TextArea inputType="text" />

The check is real — <TextArea bogusProp /> errors — so acceptance is a genuine claim of support. icon is the worst: Field.init() builds a FieldIcon instance that renderInput never renders.

Extending the Omit to all five would make types match the docs, at the cost of newly failing compiles for currently-inert props. Left out as it's wider than #1320; happy to fold it in or open a follow-up.

Verification

yarn check-types in packages/cx clean. Confirmed via throwaway files that <TextArea trim /> now errors while <TextField trim /> still compiles.