feat: Move strings to resources for localization

[LisoUseInAIKyrios]

Lays the groundwork for localizing patch strings.

See #2593

Integration changes

[oSumAtrIX]

PR #2568 will likely conflict with this one, so it's fair to look into it and merge this PR before that. I'll look into the current merge conflicts.

[oSumAtrIX]

The PR introduces some changes regarding class names in integrations. I haven't touched them, but they should ideally not include the app name in the title following this.

[oSumAtrIX]

PR #2568 introduces a patch class to add strings and other app resources. Technically, this PR could use that PR by using the introduced patch class to add strings. Still, some distinct differences make it quite hard to make this PR work together with the other PR, which is quite unfortunate as this means we will have to deal with merge conflicts one way or another eventually.

The way the other PR works is as follows. When preferences are added via the settings patch, the resource callback for each preference when the preferences are added to the app is called. This callback uses the AddResourcesPatch, which adds the strings each preference uses.
In a similar fashion, this PR could implement merging strings in the resource callback. The callback would return the keys for the strings used by the preferences and must be added to the app. In the callback, the strings patch from this PR would then look up all the strings that were returned in the callback on close and add them to the app.

This approach would eliminate the need to call StringsPatch.includeStrings() in every patch as the Settings patch would implicitly merge strings when it adds the preferences to the app, which in turn invoke the callback with the strings that are necessary for each preference. I'd say that this approach would also excuse adding all strings in a single XML file instead of separate XML files, just like it is done for the translation patch resources.

[oSumAtrIX]

I have attempted to solve the merge conflicts, but I am sure I have missed some things. I consider rewriting the PR from scratch on top of the dev branch once the other PR is merged. This is because it's not worth merging only either, as they both contain changes that would be good to have present. I am not sure how to go about this but I'll try my best.

[LisoUseInAIKyrios]

The way the other PR works is as follows. When preferences are added via the settings patch, the resource callback for each preference when the preferences are added to the app is called. This callback uses the AddResourcesPatch, which adds the strings each preference uses. In a similar fashion, this PR could implement merging strings in the resource callback. The callback would return the keys for the strings used by the preferences and must be added to the app. In the callback, the strings patch from this PR would then look up all the strings that were returned in the callback on close and add them to the app.

This approach would eliminate the need to call StringsPatch.includeStrings() in every patch as the Settings patch would implicitly merge strings when it adds the preferences to the app, which in turn invoke the callback with the strings that are necessary for each preference. I'd say that this approach would also excuse adding all strings in a single XML file instead of separate XML files, just like it is done for the translation patch resources.

This sounds interesting. My only suggestion is to keep the patch strings in separate files, as it really helps organize the strings. But I still think all patch string files can be in a single package to keep the YT resources from blowing up with 50+ directories containing a single file each (and instead it's a single directory with 50+ files). The automatic including of strings would work by the StringsPatch scanning and loading all patch strings.xml files from the Strings directory, and then include the individual strings when they are used. So it get the benefits of automatically bundling strings without needing to call StringsPatch.include(), and the patch strings are still organized into separate files.

The translated files can still be big single files for each language like they are in this PR, since the translations are treated as generated files and never manually edited or manipulated (they are automatically synced from Crowdin). The translated strings could be bundled individually as well just like the English strings, or it could do as this PR and bundle all translated strings as is so much simpler (the strings are so insignificant in size there is no real concern over wasted space).