Rule Request: [nslocalizedstring_key] Expand existing rule to support alternate localization functions to be matched.

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

New rule request

Regarding: https://github.com/realm/SwiftLint/blob/master/Source/SwiftLintFramework/Rules/Lint/NSLocalizedStringKeyRule.swift

1. Why should this rule be added?

The existing nslocalizedstring_key rule (NSLocalizedStringKeyRule) is useful however in some code bases alternate functions are used to support localization that follow the rule/pattern of NSLocalizedString. This is supported by the LOCALIZED_STRING_MACRO_NAMES build setting that Xcode uses to locate localization function that need to be process on language export.

For example in our code base we have the following build setting set that allows Xcode find and export localization keys used:

LOCALIZED_STRING_MACRO_NAMES = Localized.string Localized.text

The above matches against a set of swift static functions like the following which are value added wrappers around lower level Apple provided localization API:

//The following return a translated Swift.String

Localized.string("Hello World", comment:"main window title")

Localized.string("Welcome back %@ you have %@ worlds left to explore.", comment:"main window message", name, count)

//The following return a translated SwiftUI.Text

Localized.text("Hello World", comment:"main window title")

Localized.text("Welcome back %@ you have %@ worlds left to explore.", comment:"main window message", name, count)

2. Provide several examples of what would and wouldn't trigger violations.

The existing rule will remain unchanged other then some how accepting a configuration that outlines one or more localization function prefixes that should be matched against in addition to NSLocalizedString.

3. Should the rule be configurable, if so what parameters should be configurable?

Yes, a list of functions to match against when applying the rule.

4. Should the rule be opt-in or enabled by default? Why?

Existing rule should remain unchanged in this regard.

Start with Source/SwiftLintFramework/Rules/Lint/NSLocalizedStringKeyRule.swift, which is the existing rule named in the issue. Trace how it matches localization calls and how rule configuration is represented. Done means supporting a configurable list of additional localization function names or prefixes while preserving the existing NSLocalizedString behavior.