fix: surface silently skipped custom validators in the log

[Ibochkarev]

Validator::validate() requires any validator that isn't a built-in method (custom snippet validators, and anything like reCAPTCHA that runs through the same path) to be listed in &customValidators. That's intentional: it stops a &validate entry from brute-forcing arbitrary snippets on the site.

When a validator isn't on that list, FormIt skips it and treats the field as valid, with zero error message. The only trace is a LOG_LEVEL_INFO log line, which sits below MODX's default log_level and never actually gets written. From the template author's side, this looks identical to "my custom validator's error message isn't showing", because nothing tells them the validator never ran.

Reproduced the full path with a standalone script that stubs modX/modSnippet and exercises the real Validator::validateFields()/validate() against the docs' custom-validator example ($validator->addError($key, ...) + return a bool). With customValidators unset, fi.error.<field> stays empty and nothing in the default MODX log explains why. With customValidators correctly set, the same snippet populates the placeholder as expected, so the addError/placeholder plumbing itself is fine, only the "why did nothing happen" signal was missing.

Bumped that log call to LOG_LEVEL_WARN and spelled out the fix in the message (add the type to &customValidators).

While in there, also hardened the customValidators normalization a few lines up: $this->config['customValidators'] can arrive as an array (the constructor already explodes it from formit->config) or as a raw string (when the config passed into the Validator's constructor still carries the unprocessed scriptProperty, which overrides the constructor's array default via array_merge). The old code unconditionally called explode() on it, which throws a TypeError if it's already an array. Now it only explodes when it's actually a string.

Fixes #273