Add powder mining tracker

[Emirlol]

Powder mining tracker that tracks rewards and calculates your total profit.
This does not include the money from blocks/other drops you might gain along the way (such as sludge from jungle pick if you go down that route).

Has a configurable filter to block items from being listed and used in profit calculation.

Saves rewards to disk upon closing the game and reads from disk upon launching the game.

Also adds some chat events that are fired regardless of cancels with no modifications (realistically only against those done via fabric's events).

Some considerations

• A timer that can be started/stopped via commands or config buttons, to display alongside the total profit and powder to see average coins/powder per hour
• Perhaps a proper movable gui element? Not sure since it can go very tall and our gui elements have very opaque backgrounds. Though, it could at least be movable if not one of those gui elements.
• Some actual commands. There are currently 2 commands that were my initial way of debugging the rewards, with no categorization whatsoever. I have no idea what would be useful, though.
• Confirmation screen for the config filter? It's probably very easy considering how the list works, just didn't bother.

[AzureAaron]

This also needs to be rebased for 1.21.4

[AzureAaron]

This should be a constant unless it can't be?

[Emirlol]

It can be, but I had a better solution on another branch that is based on this so I didn't bother to change to avoid a rebase.

[AzureAaron]

Is there a reason for making chat events as opposed to using Fabric's ones?

[Emirlol]

Fabric's injection is like this:

if (ClientReceiveMessageEvents.ALLOW_GAME.invoker().allowReceiveGameMessage(message.get(), overlay)) {
	message.set(ClientReceiveMessageEvents.MODIFY_GAME.invoker().modifyReceivedGameMessage(message.get(), overlay));
	ClientReceiveMessageEvents.GAME.invoker().onReceiveGameMessage(message.get(), overlay);
} else {
	ClientReceiveMessageEvents.GAME_CANCELED.invoker().onReceiveGameMessageCanceled(message.get(), overlay);
	ci.cancel();
}

To listen to every incoming message, you'd have to register a listener to ALLOW_GAME that always returns true and never has anything to do with allowing messages or not. On top of that, if any listener before yours in ALLOW_GAME cancels it, your listener does not get called. So you have to register the same listener to GAME_CANCELED as well and complicate things even more. Oh and the 2 functional interfaces don't match due to their return values of boolean and void, so you need 3 whole methods (or lambdas) to achieve this.

This is easily solved by adding an event that passes the message to every listener without allowing any modifications, which is what the events I added do. They also don't interfere with fabric's events since they don't modify the message in any way.

[kevinthegreat1]

I've talked to fabric maintainers about this. The most probably fix that we can put in fabric is just to make ALLOW_GAME not short curcuit. But they're skeptical of such use cases, and it might help if you bring this problem up with them.

[Emirlol]

I can see why they wouldn't want to make a breaking change like that, and using ALLOW_GAME to listen to all incoming messages is still going to be confusing due to the name and the unnecessary return value, so I'm not sure if that's the solution I'd want. Perhaps I could PR this event to fabric, but I can't think of any use cases outside of this either.

[AzureAaron]

looks good