Add support for LocalizedStringResource

[connor-ricks]

A small PR to add an initializers for LocalizedStringResource for convenience.

Apple is pushing developers away from LocalizedStringKey and instead recommending they use LocalizedStringResource going forward.

LocalizedStringResource is the recommended type for representing and passing around localizable strings. It not only supports initialization using a string literal, but can also be provided with a comment, table name, or even a default value that's different from the string key.

There are a variety of benefits of resources over keys mentioned in Apple's docs.

SwiftUI views like Text and Button take LocalizedStringResource. While it is easy enough to call String(localized:) ourselves when using TextState, adding this initializer feels like a small amount of effort for a sizable convenience for consumers.

[mbrandonw]

Hi @connor-ricks, thanks for looking into this, but I think it'd be better to add a case to enum Storage for localizedStringResource instead of eagerly stringifying into a verbatim case. That way we can hand off an honest LocalizedStringResource value to SwiftUI's APIs, which I imagine has some benefits (though let me know if I am wrong).

But to do that you would need to hold onto an Any in the case and do some runtime checking under the hood. Are you down to explore that?

[connor-ricks]

Hi @connor-ricks, thanks for looking into this, but I think it'd be better to add a case to enum Storage for localizedStringResource instead of eagerly stringifying into a verbatim case. That way we can hand off an honest LocalizedStringResource value to SwiftUI's APIs, which I imagine has some benefits (though let me know if I am wrong).

But to do that you would need to hold onto an Any in the case and do some runtime checking under the hood. Are you down to explore that?

I can give this a stab at some point this week! I'm traveling today.