Don't initialize classes in mixin audit

[Earthcomputer]

There is no reason to initialize (call <clinit>) on classes for mixin audit. Doing this makes it harder to use mixin audit in unit tests, forcing you to pre-load various subcomponents of the game, and over time there is an increasing amount of them required. More generally it disrupts class loading order, that poorly designed programs may rely on.

[Mumfrey]

While it makes sense in principle I'm conscious of the spacebar heating possibilities of just changing the behaviour with no option to revert. So ideally make the new behaviour an overload for MixinProcessor::audit or expose the option as a tunable. Either option lets the host environment opt-in (or out, see below) to the behaviour change.

Remember that the original purpose of audit is to fully load any classes which haven't been loaded yet and would normally be run inside an already-fully-running game environment, where the class initialisation is, I would suggest, a desirable behaviour.

If you want to make the new behaviour opt-out that's fine, and that will depend on the values of the overload or the tunable as you decide. I don't mind either way.

[LlamaLad7]

where the class initialisation is, I would suggest, a desirable behaviour.

I would suggest that the purpose of audit is to check all your mixins apply properly, eg in integration tests. If you're going to use the classes they will be initialised as needed when you do, I'm not sure there's any benefit to initialising them early.