fix: a custom field with no help text is not an error

[blaipr]

CustomFieldDefinition.help is varchar(255) DEFAULT NULL, and getHelp() agrees it is
?string. CustomFieldItem declares string $help. ItemTrait::getCustomFieldsForItem()
passed the column straight into the constructor, so a definition saved with the Help box
left empty — which the form allows, and which is an ordinary thing to do — made every
read of that item's custom fields a TypeError.

On the web that is a 500. Through the API it is a 500 whose body carries the class, the
method and the server's absolute path, which is the disclosure shape this codebase has
already had to fix once on the parameter readers.

It is the odd one out rather than a class of problem: required and showInList are
nullable too and are cast on the lines either side, and every other column reaching this
constructor — the definition's name, the type's name and text — is NOT NULL in the
schema. help was the only one passed through as it came.

The API's category view is where this surfaced. It carries the same customFields=1
include that Client and Account do, and the fixture has two CATEGORY-module definitions
with a null help, so the endpoint answered 500 for every category. That test had been
left marked skipped with the defect written out in its docblock; it now asserts the 200
and the populated include instead.

Checked by putting the raw column back: the unit test errors with exactly
CustomFieldItem::__construct(): Argument #3 ($help) must be of type string, null given.