Decouple validation (configuration) from parsing/conversion logic.

[skwasjer]

Is your feature request related to a problem? Please describe.
Currently, parsing, type conversion and JSON conversion all rely on IIbanParser which in turn relies on IIbanValidator which in turn relies on IIbanRegistry and IIbanValidationRule. We can simplify this, by decouple parsing/conversion from validation, and instead take a direct dependency on IIbanRegistry.

The effect is that custom validation will no longer be used during parsing/conversion. While this is a behavioral change, the custom rules were originally designed to run additional business logic on user input. The use case for parsing/conversion rather is to serialize/deserialize a previously validated IBAN. Having to rerun validation logic every time is unnecessary in the latter scenarios, and it is thus better to move this responsibility to the implementor of IbanNet.

Describe the solution you'd like

• Introduce a static member IbanRegistry.Current or IbanNetConfig.CurrentRegistry of sorts which allows users to set/override the registry (eg. to add the WikipediaRegistryProvider). This property must be automatically configured for the user when dependency injection is used.
• The parser/converters are refactored to use the static member from previous bullet, when no dependency injection is used. If dependency injection is used, we resolve the IIbanRegistry from the DI container.
  • As intermediate step, the parsers/converters may use IbanRegistry.Default
• Remove IbanValidatorOptions and refactor/simplify dependency injection configuration extensions. The current registration extensions are strongly biased towards validation (dating back to when that was the only thing IbanNet offered). Custom rules and custom registry providers should from here on out be manually registered in the DI container. These are for more niche use cases which don't warrant the maintenance burden.
• Custom (validation) rules will only be used for validation and are no longer considered for parsing/conversion.
• Once this is all done, we can internalize the parser implementation, such that we can use ReadOnlySpan<T> more consistently, and shift the public API use to IParsable<TSelf> and ISpanParsable<TSelf> on the Iban type directly. (related to Add support for IParseable<T> (or ISpanParseable<T>) #133)

Challenges

• We have to consider both non-DI an DI use cases, which complicates the matter a bit.
• This is a breaking change, as this changes the behavior of parsing/conversion and requires some public API changes.