refactor: Bump ReVanced Patcher & merge integrations by using ReVanced Patches Gradle plugin

[oSumAtrIX]

About

• Bumps ReVanced Patcher
• Uses ReVanced Patches Gradle plugin
• Merges integrations

Todo

• Merge commit history of ReVanced Integrations
• Bump dependencies to stable (Patcher, lib)
• Sync with build(Needs bump): Bump ReVanced Patcher to v20 revanced-manager#2242
• Sync with https://github.com/ReVanced/revanced-api (already released but needs to deployed on our server)
• Test patches
• Fix consistency (top-level EXTENSION_CLASS_DESCRIPTOR or local extensionClassDescriptor, for example) (Should be converted to extensionClassDescriptor eventually)

Merge instructions

• This PR should be merged as two commits:
  1. A commit that highlights the ReVanced Patcher bump.
  2. A commit that highlights the merge of integrations

The first commit may have residues from the second commit.

[oSumAtrIX]

@LisoUseInAIKyrios This PR is now ready for review/mergeing. Before we merge I will try to force push the integrations history into this branch and merge by rebasing. Since there are many objects the repository will grew a bit on size due to stuff like the Gradle wrapper being committed to. I could rewrite history in a way where only commits to the source files are included. This skews true history, but avoids bloating the repo with commits that will be forgotten anyways in a while. What do you say?

The PR surely has some errors/mistakes which we will see when it reaches main at least. Before merging this, I will to do a superficial test.

[LisoUseInAIKyrios]

Only the history of source code files is useful, so that would be preferable.

I can review tomorrow.

Build failed with out of memory. Locally I had to increase gradle memory argument as recently it had been complaining about running low.

FAILURE: Build failed with an exception.

* What went wrong:
Java heap space

[oSumAtrIX]

Merging this means all other current PRs need to be rebased and resolve merge conflicts. I can take up on some. Since sources are moved its simply a matter of rebasing, and during merge conflict resolution copy over the old source files to the new place and apply the necessary changes.

[oSumAtrIX]

Build failed with out of memory. Locally I had to increase gradle memory argument as recently it had been complaining about running low.

Odd. Maybe environmental specific. Gradle orchestrates a parallelized build for all subprojects such as extensions and the patches project:

[oSumAtrIX]

I have merged both histories now:

First the integration commits are rewritten only to include changes to the source files:

The rewrite moved all commits to the source files to a directory "intregrations". This allowed for a merge commit without conflicts into the patches repo. The merge was stopped with --no-commit and the commit that converted the integrations to an extension was applied to the pending merge. The integrations directory was deleted, the extensions folder created, and the merge finished:

Regarding new commits to this branch, I am unsure how git handles this merge as the last commit. So far, I have been doing fix commits and then squashing them with the Bump patcher commit, but since there's a merge in between, this may not work. In this case the last commit can be reverted, the commits pushed and then I can do them again.

[LisoUseInAIKyrios]

Everything seems to be working ok.

[LisoUseInAIKyrios]

In a different commit, the packages of the patch files could be reorganized, as they still use the old settings groups of interaction, layout, etc.

[oSumAtrIX]

I was thinking of getting rid of the structure entirely and just structure by package name. All patch files would be next to each other. Fingerprint files could be named the same way as the corresponding patch too (HideAdsFingerprints.kt for example). I think this is easier to read.

[LisoUseInAIKyrios]

Yeah since most patches have only 2 files that would work.