Document that 8.x-1.1 configuration keeps working via field_validation_legacy after upgrading to 3.0.0

Problem/Motivation

Between 8.x-1.1 and 3.0.x every validation rule plugin was rewritten on top of Symfony's Constraint API and given a new plugin ID (e.g. email_field_validation_rule became email_constraint_rule; some, like blocklist_field_validation_rule and integer_field_validation_rule, have no direct successor at all in the main module). None of the original 8.x-1.1 plugin classes or IDs exist in field_validation 3.x anymore.

On its own, that would mean any field_validation.rule.* config exported under 8.x-1.1 stops resolving after a straight upgrade — the plugin ID it references no longer exists, so the rule silently stops validating.

That risk was already addressed once, in #3377899: Move original validation rule to field_validation_legacy module: the original plugins were moved verbatim into a companion submodule, field_validation_legacy, under their original plugin IDs. A site that enables that submodule keeps its 8.x-1.1 rule configuration working as-is. I confirmed this by diffing the 8.x-1.1 and 3.0.x tags directly — field_validation_legacy ships all 20 original plugin classes under unchanged IDs, each with its own Kernel test, and the field_validation_rule_set config entity itself (FieldValidationRuleSet.php) is byte-identical between the two tags, so ruleset-level config needs no changes at all.

What's missing is telling anyone this is the case:

• Nothing in the README, module description, or an upgrade path/UPDATE.md mentions that field_validation_legacy must be enabled to preserve 8.x-1.1 configuration.
• There's no hook_update_N or requirements warning that flags this for a site mid-upgrade — a site that just runs composer update and drush updb gets no signal that its existing rules need the legacy submodule to keep working.

Proposed resolution

• Add a short section to the README (or a new UPGRADE.md) stating plainly: sites upgrading from 8.x-1.1 must enable field_validation_legacy to keep existing rule configuration working, and that new rules going forward should use the Constraint-API-based rules in the main module.
• Consider a hook_requirements() check (update phase) that warns when field_validation.rule.* config references a plugin ID that only exists in field_validation_legacy and that module isn't enabled.

Remaining tasks

• Write the documentation.
• Decide whether the requirements-check is in scope for 3.0.0 or a follow-up.

User interface changes

None, unless the requirements-check is included (adds a status/requirements page warning).

API changes

None.

Data model changes

None.

Related: #3616699: [Meta] Road to 3.0.0, #3377899: Move original validation rule to field_validation_legacy module