Fix AddCarter when DependencyContext is unavailable in single-file publish

[seifmaazouz]

Summary

DependencyContext.Load() returns null for single-file published apps (see dotnet/runtime#70438). Carter currently assumes a DependencyContext is always available, causing AddCarter() to fail during startup. This PR adds a fallback for that scenario while leaving the existing DependencyContext path unchanged.

Changes

• Fall back to AppDomain.CurrentDomain.GetAssemblies() when DependencyContext is unavailable.
• Preserve the existing discovery behavior when DependencyContext is available.
• Skip validators with unbound generic parameters during discovery to avoid registering open generic validator types.

Testing

Normal application

Verified that discovery matches the current behavior:

• Assemblies discovered: 3
• Validators discovered: 4
• Modules discovered: 8

Single-file publish

Published the sample application as a single-file executable and verified that:

• AddCarter() no longer throws during startup.
• Modules are discovered and registered correctly.
• Validators are discovered and registered without DI registration failures.
• The application starts successfully.

Observed counts:

• Assemblies discovered: 78 (includes framework assemblies already loaded by the runtime)
• Validators discovered: 3
• Modules discovered: 8

The missing validator belongs to an assembly that isn't loaded by the runtime in the single-file application, so it can't be discovered once DependencyContext is unavailable.

During testing I found that scanning all loaded assemblies includes FluentValidation's own open generic validator types (for example InlineValidator<T>). Without the generic parameter check, DI registration fails with:

System.InvalidOperationException: Cannot instantiate implementation type 'FluentValidation.InlineValidator`1[T]'.

This PR skips validators that still have unbound generic parameters to avoid that failure.

Notes

The fallback can only discover assemblies that have already been loaded by the runtime. Assemblies that are never loaded can't be discovered once DependencyContext is unavailable. This matches the limitation described in dotnet/runtime#70438.

I intentionally left the fallback unfiltered (it scans all loaded assemblies) because reducing that scan would be an optimization rather than a correctness fix. I'd be happy to explore that separately if it would be useful.

Fixes #383.