Sponge module refactoring and fixes

[Vilsu221]

Fix items drop when making block changes.

Implement sendBiomeUpdates.

Move listeners into own class.

[wizjany]

In general, I'm unsure that we actually want all the changes from MC to Sponge classes/methods. Given that most of the Sponge API is just implemented via mixin, the only thing this really accomplishes and pushing the we-sponge code base even further from we-fabric/we-neoforge (making it harder to maintain), and there's several places where sponge classes are just cast back to MC classes anyway.

If this PR just had the block/biome fixes and maybe even the event listener refactor (though see my comments), it would be a lot easier to pull, but right now I feel like there's too much that isn't necessarily a benefit.

[Vilsu221]

In general, I'm unsure that we actually want all the changes from MC to Sponge classes/methods. Given that most of the Sponge API is just implemented via mixin, the only thing this really accomplishes and pushing the we-sponge code base even further from we-fabric/we-neoforge (making it harder to maintain), and there's several places where sponge classes are just cast back to MC classes anyway.

If this PR just had the block/biome fixes and maybe even the event listener refactor (though see my comments), it would be a lot easier to pull, but right now I feel like there's too much that isn't necessarily a benefit.

In my opinion Sponge API is more "stable" than MC.

[me4502]

given we're working with multiple platforms that are Minecraft code, from a maintainability perspective it's often better. Any potential benefits are immediately removed by all (from what i can tell) spots where you've swapped over to Sponge code requiring casting back to MC native code anyway.

I agree with wiz in that splitting out the biome & block fixes would be significantly better than this PR as-is. it's doing too much at once, and they're not all changes that make sense for us to merge.