feat(AddResourcesPatch): Support adding resources directly from the patch resources with localization for strings in mind

[oSumAtrIX]

About

This PR is based on the music-check-for-gmscore branch and depends on it being merged.
This PR aims to add support for the AddResourcesPatch to be able to add resources that are present in the patches. The sidequest it solves this way is to support localization for strings simultaneously by doing that.

The PR is heavily inspired by PR #2440 and aims to supersede it in a more generic way by getting rid of a dedicated "translations" patch.
It does so by providing the ability to add strings to a .json file in the resources. At the same time, it will add alternative strings in other languages under the same resource directory, such as values-de. In general:

• Adds strings from resources/addresources/strings.json to res/values/strings.xml
• Adds strings from resources/addresources/values-<language> to res/values-<language>/strings.xml
• Adds other implementations of BaseResource to the app's resources such as arrays

Todo

• The PR is in its early stages to discuss and make revisions before starting with the implementations.
  The plan is to make each implementation of BaseResource handle the logic of adding itself to the app's resources. This way, the AddResourcesPatch can iterate over its BaseResources and invoke resource.add(...), for example, which will make the resource add itself to the corresponding app's resources.
  This will prevent having to cram everything into AddResourcesPatch#close, and in case new kinds of BaseResource are implemented (for example, through the public API), the open-closed principle is not violated for AddResourcesPatch#close
• Complete the functionality of AddResourcesPatch to add resources from the patches resources folder and to be able to add specific resources manually. Some patches may want to add strings or other kinds of resources without creating a resource JSON file in the patches.
• Implement some edge cases present in feat: Move strings to resources for localization #2440 regarding escaping for example
• Modify SettingsPatch preferences so that they only specify the key just like in feat: Move strings to resources for localization #2440
• Add AddResourcesPatch to all patches that need it
• Migrating all strings to resources
• Implement integrations (feat: Move strings to resources for localization revanced-integrations#420 should work)

[oSumAtrIX]

@LisoUseInAIKyrios I have gone with something similar to your initial design by asking for a single .json file for strings. The json file is cascaded to allow only the necessary strings to be added. If AddResourcesPatch#invoke is called with the patch, just as the inline documentation explains, it'll add the patch strings to the app and any localization. It will do so by accessing the strings in stringsJson["youtube"]["ads.general.GeneralAdsPatch"] whereas it extracts the keys from the patches full qualifier.

This structure has been chosen to reduce duplicate json keys.

[LisoUseInAIKyrios]

If I understand this, all strings would go into the single strings.json file and the strings are grouped by patch/class name.

If two different patches use the same strings (such as GMSCore for YouTube and YT Music), how is that handled?

[oSumAtrIX]

As of now, the patch reads the strings that match to the current class. For abstracts and so on it would still look up the strings using the class of the abstract class implementation. An approach to solve this would be to pass down the class to the function. This way the abstract class would be used to lookup the strings instead of the implementation of that abstract class.

[oSumAtrIX]

@LisoUseInAIKyrios, I have made a small change regarding this. I have noticed you may be referring to "shared" strings. Similarly to that in #2440. I'd imagine this would be useful if you have say a string "Ok" that would be duplicated across patches. Is there a scenario where this is imaginable? As of now, all patches that share strings also have a common super class in which the strings are present.

[LisoUseInAIKyrios]

I'm sure a situation can exist where generic strings are shared. But it could be done using this PR as a simple shared patch that only has strings. It might be a little bloated using a patch only to include strings (instead of merging/including a string file) but it would work.

[oSumAtrIX]

Another idea I had stashed and deleted was a "shared" object in the JSON similar to the shared package in the patches. Somehow patches could reference the strings and AddResourcesPatch would pick them from the shared path. Not sure how to go forward with this idea yet.

[oSumAtrIX]

@LisoUseInAIKyrios Apart from the remaining TODOs, I've settled with what's pushed. If you do not have any comments, I'll finish with the implementation.

One PR change to consider is that the patch reads all resources from the XML files on execution and holds them in memory as BaseResource instances. This was done to be able to instantly add BaseResource instances to the patch as part of its design, instead of first staging PatchClass in a list and then on close of the patch, reading the resources, and adding them to the app's resources. Doing it using the latter method would spare the overhead of converting the XML nodes to BaseResource and keeping them in memory. Still, as part of the patch design (Add BaseResource, and then close merge them), I've settled with this unless we want to change that.

[LisoUseInAIKyrios]

Yes this plan looks good

[LisoUseInAIKyrios]

To verify the merging of translations works, one or more non-English languages can be added. Can use machine translations for these.

[oSumAtrIX]

I am now finished with this PR, but some mistakes may have still been made:

• Strings are not correctly escaped
• Strings that have been removed in this PR may have been included (the XML files were generated off the latest dev branch)
• Strings that may have been modified in this PR are not applied in the XML because the XML files were generated off the dev branch)
• Since the title and co. are inferred from the key, it is possible that we have named a title string incorrectly so that, due to inference, the title string will not be found, but the AddResourcesPatch should throw an exception in such a case

The merge process will look the following way:

1. fix(YouTube - GmsCore support): Gracefully exit when GmsCore is not running LisoUseInAIKyrios/revanced-integrations#2 is merged (by @LisoUseInAIKyrios)
2. feat: Move strings to resources for localization revanced-integrations#420 is merged
3. This PR will be merged to feat/music-check-for-gmscore
4. feat/music-check-for-gmscore will overwrite LisoUseInAIKyrios:localization
5. feat: Move strings to resources for localization #2440 is merged

[oSumAtrIX]

I remember one string was "null_summary", so I converted this PR into a draft to find it. This should be as easy as observing StringResource construction