Obviously making a setter is pointless.
You want to override a getter.
Block#getCollisionBoundingBoxFromPool(World, int, int, int) and Block#getSelectedBoundingBoxFromPool(World, int, int, int) are probably what you'd like to use.
The order in which you Container#addSlotToContainer is really important.
You need to keep it in mind when writing #transferStackInSlot.
In your current state, you are adding 36 slots from player inventory, then 1 "output slot", then 9 "input slots". But your tile entity has 17 item slots.
It can, actually.
Just look at .minecraft/versions/<some version>/someversion.json , it has a "libraries" tab.
You may want to build an "installer" like Forge to automate this. Fortunately, Forge installer is open-source, so you don't have to think too much about it.
In case you haven't learned it yet, that is not how @Mod is used. Look at the basic tutorials on the wiki.
As for events, i recommend PlayerPickupXpEvent.
Coremod are for advanced patching of Minecraft.
What you describe is not a coremod.
You are just spliting into modules, which is doable with no more knowledge than any other mod.
Just move the built jar from the main mod into the folders of each modules, so that gradle will be able to built them.
Make an access transformer configuration file. ForgeGradle will pick it when setting the workspace and apply changes.
You could also consider reflection, which is less troublesome.
You can add 'FMLAT: "yourFile_at.cfg"' to your META-INF/Manifest
then, put the transformer config in the same folder.
This way you don't have to make a LoadingPlugin and a coremod.