Add Static Extractor Support

[MikeAlhayek]

With this PR we can use static successors instead of having to inject localizer using DI.

public static class StaticLocalizers
{
    private static IStringLocalizerFactory _stringLocalizerFactory;

    public static void Configure(IStringLocalizerFactory stringLocalizerFactory) =>
        _stringLocalizerFactory = stringLocalizerFactory;

    public static TypedStringLocalizer<T> S<T>() => new(_stringLocalizerFactory.Create(typeof(T)));

    public static TypedStringLocalizer<T> T<T>() => new(_stringLocalizerFactory.Create(typeof(T)));
}

public readonly struct TypedStringLocalizer<T>(IStringLocalizer localizer)
{
    public LocalizedString this[string name] => localizer[name];

    public LocalizedString this[string name, params object[] arguments] => localizer[name, arguments];

    public LocalizedString Invoke(string name) => localizer[name];

    public LocalizedString Invoke(string name, params object[] arguments) => localizer[name, arguments];

    public LocalizedString Plural(int count, string singular, string plural) =>
        localizer[count == 1 ? singular : plural, count];
}

[hishamco]

Why static over DI?

[MikeAlhayek]

It'll make it so much easier to use and also allow us to localize static string like Permission in OC. but also won't force us into needing multiple constructor in cases like this https://github.com/OrchardCMS/OrchardCore/pull/19198/changes.

[hishamco]

@sebastienros, while you approved the related PR, are you OK with this PR? It's an anti-pattern that reminds me of a service locator

[sebastienros]

Why do we need to model custom S/T static helpers instead of trying to detect something likw new LocalizedString("Foo") ?