Fix state leakage of otherCountryCodes in IBANValidator custom configurations

[sahvx655-wq]

This PR fixes a state consistency issue in mutable IBANValidator instances where associated territory codes (otherCountryCodes) could remain mapped to obsolete validator instances after a validator was removed or replaced.

Some validators define additional territory codes through otherCountryCodes (for example, FR includes GF, GP, MQ, etc., and GB includes IM, JE, GG).

When setValidator(...) was used to remove or replace a validator, the implementation updated only the primary countryCode entry in validatorMap. Any entries created for otherCountryCodes were left untouched.

As a result, territory codes could continue resolving to a stale validator that was no longer registered, causing inconsistent validation behavior and leaving validatorMap in an incorrect state.

The validator update logic has been extended to keep all related mappings synchronized:

• When a validator is removed, any associated otherCountryCodes mappings are removed as well.

• When a validator is replaced, mappings belonging to the previous validator are cleaned up before registering the new validator and its associated territory codes.

• The internal validatorMap now remains consistent after validator additions, replacements, and removals.
  Added regression tests in IBANValidatorTest covering:

• Removal of a validator with associated otherCountryCodes

• Replacement of a validator with associated otherCountryCodes

• Verification that stale territory-code mappings are properly cleaned up

• Verification that new territory-code mappings are correctly registered