Add a fluent Validate overload for adding validator types

[89netraM]

Adds a Validate overload to the OptionsBuilder that registers an IValidateOptions type that validates the option type.

Closes #115200

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-options
See info in area-owners.md if you want to be subscribed.

[tarekgh]

The existing Func<>-based Validate overloads pass Name to ValidateOptions, so validation is scoped to the OptionsBuilder's named option:

 // Only validates option named "A"
 services.AddOptions<MyOpts>("A").Validate(o => o.X > 0);

The new Validate() registers the type directly; the validator sees all option names, not just the one on this builder. Whether it filters by name is entirely up to TValidateOptions. This is inherent to the IValidateOptions<T> interface design, but it's a behavioral difference users might not expect from a method sitting alongside the name-scoped overloads.

[tarekgh]

Could you add a couple more test cases?

1. Validator with constructor-injected dependencies; this is the key scenario the API enables (e.g., [OptionsValidator]-generated types) and would exercise the DynamicallyAccessedMembers(PublicConstructors) annotation. Something like a validator that takes an ILogger or a custom service in its constructor.

2. Named options; verify behavior when the OptionsBuilder is configured with a non-default name (e.g., AddOptions<ComplexOptions>("myName")). Since unlike the Func<>-based Validate overloads, this method doesn't scope to the builder's Name, it would be good to have a test that documents this behavior explicitly.