Feature request: Config option to disable tamper checking for certain abilities

[CplPibald-2]

java.lang.RuntimeException: stacktrace
        at knot/io.github.ladysnake.pal.impl.PalInternals.logTamperWarning(PalInternals.java:63) ~[playerabilitylib-1.10.0-23a75d3248fcb0d2.jar:?]
        at knot/io.github.ladysnake.pal.impl.VanillaAbilityTracker.checkConflict(VanillaAbilityTracker.java:71) ~[playerabilitylib-1.10.0-23a75d3248fcb0d2.jar:?]
        at knot/net.minecraft.class_3222.handler$cgd000$playerabilitylib$checkAbilityConsistency(MixinServerPlayer.java:11703) ~[server-intermediary.jar:?]
        at knot/net.minecraft.class_3222.method_7355(MixinServerPlayer.java:1552) ~[server-intermediary.jar:?]
        at knot/rearth.oritech.block.entity.augmenter.api.CustomAugmentsCollection$2.refreshServer(CustomAugmentsCollection.java:71) ~[oritech-fabric-0.16.2.jar:?]
        at knot/rearth.oritech.block.entity.augmenter.PlayerAugments.refreshPlayerAugments(PlayerAugments.java:30) ~[oritech-fabric-0.16.2.jar:?]

When you load PAL with a mod that changes attributes outside of it, PAL seems to be going out of its way to intentionally break the other mod. I understand why it does this, but in certain cases, it results in far worse behavior than just letting the conflict go. Such is the case, for example with mods that add a permanent flight ability like Oritech's augments. Every few seconds, Oritech tries to re-apply minecraft:mayfly on the player, only for PAL to disable it.

The suggested fix on PAL's page is to ask the mod author to support PAL, and if the author is willing, I agree this is the best solution. But if the mod author is not willing to add support, then modpack makers and server admins have zero options to resolve the problem.

This feature request is to allow pack makers and server admins to be able to disable tamper checking, as an intermediate fix for mod incompatibilities.