#2293 - Cleaner implementation of some particular ocProducts non-bundled addons

I would recommend the warnings bundled addon to also work via. hooks. That way, certain features / addons can have their own entries in the punishment form. For example, say if I create an addon where users earn charms for their profile... and I want staff to be able to revoke charms as a form of punishment. The addon can then create a hook for the punishment form allowing me to choose charms to revoke for that user.

Another reason would be if I decide to make and release my karma addon. It'd be much easier to implement into the warnings system via. hooks.

We'll approach this in a number of different ways, as there's no one-size-fits-all solution here. We don't want a proliferation of hooks that only exist due to the perculiar needs of particular addons.

1) comcode_whitelist - in v11 branch I have reimplemented this using hooks

2) referrals - in v10 branch I have done something I've called "psuedo-hooks", which is search and replace still but tied to specific static comment markers in the code

3) workflows - this is awkward as there is a lot of overridden code that is too specific for hooks, and the addon really should be a fully integrated feature. For now I want us to merge some changes into core, and make it so other changes only even run if a value flag is set. The addon documentation can say that it is not being maintained and you need to enable the flag. i.e. we'll leave it to rust and turn it off even for dev installs - until we can get some sponsorship to make it a proper integrated feature.

4) composr_homesite_support_credits - change overrides to hooks

5) support hooks in the warning addon

I've done some of this, but I have also made the dynamic code-rewrite system more robust than str_replace.

Workflows and hooks for warnings will be discussed in other issues.