Fix manager and modules tripping DCL protection on GrapheneOS

[Enovale]

Things of note:

• I have not tested this on a non-grapheneos device
• I have not tested this on old versions of grapheneos, but the patch seems very resilient to change
• I have been wondering if it's possible for modules to trigger Storage DCL but I have yet to see any so it is not patched here
• I think it'd be helpful/possible without increasing the complexity of the patch too much to force-allow DCL for apps that are selected as a scope in any enabled module, since the user would be doing that anyway. Just not sure how to do that in the simplest way, since all the data needed to calculate that seem to be in other places than the zygisk process.

[JingMatrix]

I don't think it is really needed to add variable DGRAPHENE_SETTINGS_PACKAGE_NAME, since all OS setting package has this name com.android.settings.
Instead we should find a way to accurately detect Graphene OS. Maybe they have special build property ?

It is better that you put your code of hook in a separated class intead of inside [ParasiticManagerHooker.kt‎], where you could probably pre-define a set of packages where the DCL hook should be applied.

[Enovale]

we should find a way to accurately detect Graphene OS. Maybe they have special build property ?

We should be able to know it's graphene simply by the class existing. Trying to "prove" it's grapheneos seems needlessly strict otherwise.

you could probably pre-define a set of packages where the DCL hook should be applied.

Adding more things to the list is not the issue, the issue is getting the list of currently enabled scopes from the config cache. I've tried adding a method to the daemon bridge to request all scopes, and it typically works, but it's randomly blank sometimes and the patch doesn't work overall. Not sure why.