ValidatorOptions is not publicly exposed

[BriceFab]

Describe the bug
I’m trying to override the email validation regex, but ValidatorOptions is not publicly exposed by the package API. Because of this, I cannot set a custom emailRegExp either globally (via ValidationBuilder.globalOptions) or locally (via the options constructor parameter).

According to the source, ValidationBuilder relies on _options which defaults to globalOptions, and email validation uses _options.emailRegExp. However, without being able to import ValidatorOptions, there’s no supported way to provide a custom regex.

References:

• Package page: https://pub.dev/packages/form_validator
• Implementation snippets:
  • ValidationBuilder.email uses _options.emailRegExp.hasMatch(v)
  • ValidationBuilder.globalOptions = ValidatorOptions()
  • ValidationBuilder({ ValidatorOptions? options, ... })

Expected behavior
Provide a supported, public API to override the email regex:

• Either expose ValidatorOptions publicly so it can be imported and instantiated by client code, and allow:
  • Global override via ValidationBuilder.globalOptions = ValidatorOptions(emailRegExp: myRegex)
  • Local override via ValidationBuilder(options: ValidatorOptions(emailRegExp: myRegex))
• Or add dedicated API to set custom regexes (e.g., ValidationBuilder.setEmailRegExp(...) or ValidationBuilder.configure(options: ...)) without needing to import ValidatorOptions.

Actual behavior
ValidatorOptions is internal/non-exported, so overriding the email regex isn’t possible via public API.

Minimal reproduction

1. Add form_validator to a Flutter project.
2. Try to import and use ValidatorOptions to set a custom emailRegExp.
3. The symbol isn’t exposed, making custom email regex configuration impossible.

Environment

• form_validator: 2.1.1
• Flutter/Dart: (your versions)
• Platforms: Android/iOS/web

Proposed solutions

• Publicly export ValidatorOptions from the package entrypoint; or
• Introduce public setters or configuration hooks (global and/or per-builder) to override built-in regexes.

Additional context
This is a common need (e.g., stricter TLD constraints, disallowing underscores in domains, compliance with specific product rules). Exposing configuration would keep the library flexible while preserving current defaults for existing users.

cc @themisir