Add option to configure ValidationContext

[Shipibo303]

Description

This PR adds a new ConfigureContext parameter to FluentValidationValidator. This parameter allows users to pass an Action to modify the ValidationContext before it is passed to FluentValidation validators.
This solves the issue in #183, also addressed in #156, but instead of just allowing you to set RootContextData, it provides more robust access to ValidationContext configuration.

Why is this needed?

Currently, Blazored.FluentValidation does not provide a way to customize the ValidationContext used when validating a model. FluentValidation provides powerful context features, that Blazor users could make use of.

Why is this better than just allowing RootContextData?

• RootContextData is static per validation execution, while ConfigureContext allows for dynamic modifications.
• FluentValidation's ValidationContext<T> contains more than just RootContextData—it also allows setting a custom selector or defining a property chain.
• More flexibility for complex validation scenarios where RootContextData alone would be insufficient.

Example Usage

<FluentValidationValidator ConfigureContext="@(ctx => ctx.RootContextData["UserRole"] = userRole)" />

This ensures that validators can access UserRole dynamically during validation.

Unit tests of this feature are also included in the PR.

[LuukGlorie]

Nicely done!

[NandanDevHub]

Hey Buddy there are few things you can maybe check to add option to configure

1) Define/guarantee invocation order vs Options

Love the new ConfigureContext hook. One thing: the order relative to Options (which configures the ValidationStrategy) isn’t obvious. Right now ConfigureContext runs right after context construction:

// EditContextFluentValidationExtensions.cs
fluentValidationValidator.ConfigureContext?.Invoke(context);

you can document and enforce an order e.g., run ConfigureContext first, then apply Options, so callers can override the selector set inside ConfigureContext if needed. A small unit test asserting the order would prevent regressions.

2) Minor API polish: XML docs + sample

In FluentValidationValidator, you can add XML docs for ConfigureContext that show a real‐world example using RootContextData (which ofcourse matches the test you added), and call out the FluentValidation guidance on context usage for discoverability.

/// Allows customizing the ValidationContext (eg. setting RootContextData, a custom selector)
/// before validation runs.
[Parameter] public Action<ValidationContext<object>>? ConfigureContext { get; set; }

For Reference: FV docs for ASP.NET and DI.

---

Also other than that in ParamValidationContext/Tests.cs, after clicking submit you already wait for Valid in the happy path. You can Consider doing a similar WaitForState on the error paths to avoid flakiness under slow CI.