Mixin package refactor

[Alexdoru]

Moved all mixins from mixins package to mixin/mixins package so we can put the mixins related hooks and other classes in the mixin package and not have them sit in a common package

[github-actions]

Warning: 2 uncommitted changes
#248

[glowredman]

Tbh I don't see the point. Just changing the common package to a different name should suffice, if at all. Thoughts, @mitchej123?

[Alexdoru]

when you make mixins you sometime needs external interfaces to call methods or you create class hooks and it makes sense to put them under a mixin package that's all

[glowredman]

I completely understand what you mean, I just don't agree. When I see a package called "mixin(s)" I expect everything inside to be directly responsible for bytecode manipulation via the Mixins framework and nothing else.

[Alexdoru]

So are you saying that when you see such a refactored package you don't understand where the mixins are ?

And you would rather have mixin stuff spread accross two package with a second package that isn't even named mixin ?

[glowredman]

So are you saying that when you see such a refactored package you don't understand where the mixins are ?

I am not a machine, I can work things out when they don't meet my expectations.

And you would rather have mixin stuff spread accross two package with a second package that isn't even named mixin ?

Yes because one of these doesn't actually contain mixins, the classes are just somewhat related. ItemBlocks don't belong in an item(s) package either. They are related to blocks but aren't actually blocks.

[Alexdoru]

I guess we disagreee, @mitchej123 what do you think ?

[mitchej123]

I'm not a fan the mixins being nested, so I'm with glowredman on this one