Add richtext custom field support

[AndrianBdn]

Summary

QA Sphere now supports rich text custom fields — notably the new Description field, exported as a custom_field_richtext_description column with a JSON-encoded value. This adds a richtext type so CSV import converters can target it properly instead of dumping source-TMS descriptions into Preconditions.

• New CustomFieldTypeRichtext ("richtext"), included in validation, producing custom_field_richtext_<systemName> headers.
• Removed the max=255 cap on CustomFieldValue.Value. Verified against the QA Sphere backend: custom field values are stored as TEXT with no length validation for any type — the cap never matched a real constraint. The only real limit is indirect: dropdown values must match a defined option, and option values are VARCHAR(255) — so 255 is now enforced for dropdown values only, giving early feedback on the one case that would actually fail import.
• Documented the value format: richtext values are HTML (e.g. <p>…</p>, <pre><code>…</code></pre>), unlike Preconditions/Steps which take markdown. The backend sanitizes richtext via a bluemonday tag allowlist (disallowed markup is stripped). Doc comments on the type + a new "Custom Fields" README section.
• Updated the TestCase.Preconditions doc comment to stop suggesting it for descriptions.

Verification

• Output round-trips against a real QA Sphere export (backup_DES.csv from the DES demo project): same header, same {"value":"<p>…</p>"} cell format. The library additionally emits isDefault:false, which the import parser explicitly accepts (it reads only value/isDefault; extra keys are ignored) — existing text/dropdown output stays byte-identical.
• New test builds a ~700-char multi-line HTML value with quotes/commas/newlines, parses the generated CSV back, and asserts the exact value survives escaping.
• New test covers a 600-char text value now validating; the old >255 failure fixture was repointed at a dropdown field, where rejection remains correct.
• make test and make lint pass.