Overhaul and Kotlinize all lighting code

[TheBuilderBoy76]

Title. Extends work completed in #359. Three main areas of focus:

• Implement the halogen bulb behavior for all other bulbs. Essentially, convert all lamp socket ranges to be dependent on bulb type (currently only implemented by the floodlights). Make all bulbs emit light at the same base brightness (15). Clean up the bulb registration and lamp aging code. Possibly increase power draws of different bulbs.
• Kotlinize all lighting code and consolidate the files. Attempt to share as much code as possible between the floodlights/streetlights and sixnode lamp sockets. This would make adding new lights and maintaining the code much easier.
• Look into rewriting the code for the ghost light blocks (how the lamp sockets currently produce light) and the lamp supplies.

[TheBuilderBoy76]

Something else: There currently exist two ways to disable lamp aging: an internal /eln command (toggles aging for all bulb types) and the config file (toggles aging for a few individual bulb types). These two methods appear to be mutually exclusive - each can be enabled/disabled without affecting the other. I propose synchronizing the config file with the /eln command and adding subcommands for each bulb type, similar to how the watchdog command is implemented.

And another issue that I wrestled with a while ago without any success: Shift-clicking a bulb out of a lamp socket (from inside the GUI) while bulb aging is enabled temporarily duplicates the bulb, copying it back into the lamp socket from the player's inventory. This "ghost bulb" does not trigger the lamp socket to turn back on (the server does not register that it is there) and disappears when the GUI is closed. However, repeatedly shift-clicking the bulb duplicates it over and over for the player, and the duplicates in their inventory remain after closing and reopening the lamp GUI. I suspect that this issue is going to be difficult to find a fix for, though it would be nice if someone could prove me wrong.

[jrddunbr]

I would test the inventory bug again. In a recent PR, I fixed many locations in the code where inventory state was not being synchronized correctly by dirtying the inventory state.

The aging stuff is quite complicated; this is one of the few things actually saved against a world and not a config file. It probably can be moved to config.

[TheBuilderBoy76]

For the inventory bug: it does not appear to be fixed. Also, infinite duplication is not actually possible - I misremembered how it works. Interacting with the duplicate bulb eventually causes it to disappear, either from the player inventory or the floodlight GUI. Either way, the bulb item is not permanently duplicated.

As for the aging - I guess it makes sense for bulb aging to be saved per-world. There's gotta be a better way to implement it though. Maybe something like "/eln lampAging [local/global] [bulb-type] [true/false]", where "local" saves the changes to the world, and "global" saves the changes to the config file.

[jrddunbr]

Also, infinite duplication is not actually possible - I misremembered how it works. Interacting with the duplicate bulb eventually causes it to disappear, either from the player inventory or the floodlight GUI. Either way, the bulb item is not permanently duplicated.

This is typically because the server knows the bulb doesn't exist, but the client's inventory is not updated/dirtied. This is probably due to a missing inventory.setDirty() call somewhere.

There's gotta be a better way to implement it though. Maybe something like "/eln lampAging [local/global] [bulb-type] [true/false]", where "local" saves the changes to the world, and "global" saves the changes to the config file.

I'm indifferent to whether we keep it as a per-world thing; implement the command based on what makes sense to you. I'd think that it's valid both ways; maybe server operators want it one way but map creators want it a different way. I doubt we'll see any map creators for this though so I'd err on the side of making it a server config and drop the world config.