feat: utilise string localisations

[russellwheatley]

PR contains string localization implementation.

A couple of things to note;

• There are no strings as far as I can see for verifying email so I left VerifyEmailView as it is, until the below question is resolved.
• I haven't touched the Facebook, Phone or Google provider Swift package until the question below has been resolved.

Questions

1. Should we keep all strings within the core package? If they need to be within their own Swift package (e.g. Facebook strings in Facebook Swift package), then this would require some refactoring to the internal implementation so we can make use of each packages Bundle.module which contains the strings.
2. Should we add strings to the string catalog for missing strings such as verifying email?

[morganchen12]

Should we want to keep all strings within the core package? If they need to be within their own Swift package (e.g. Facebook strings in Facebook Swift package), then this would require some refactoring to the internal implementation so we can make use of each packages Bundle.module which contains the strings.

Though it's a big of an abstraction-break I think we should given the localization bundle override is in the core package and strings themselves aren't stateful and have no dependencies. Overall I expect the strings required for 3P auth providers to be minimal since those dependencies (GoogleSignIn etc) also do their own localization.

Should we add strings to the string catalog for missing strings such as verifying email?

Yes, if you can add placeholders that'd be great. I'll fill them in with internal l10n resources async and they shouldn't be a blocker for this project. In the meantime Xcode will display whatever you use as a placeholder.