Fix: Place multiblock gates with proper initial states in the presence of adjacent redstone

[hugeblank]

When setting up the signals before placing down an adder, and then placing it down, the input states appear incorrectly:

This PR fixes that, and changes a few subjective things, mostly to do with the adders:

• Changed BLOCK_PART state names (and their respective multiblock model/texture file names/paths) from top/bottom to left/right. The names are derived from the direction the output is pointed, which is the opposite of the facing block state field. This means that if the center has a facing of north, to get to the the right block part you have to use pos.offset(state.get(FACING).rotateYCounterclockwise()) (to the left). I did this to make it more clear what the state parameter is, but it only really makes sense when looking at the f3 debug screen. Depending on input I'm wiling to change this so that it matches the developers perspective.
• Replaced the use of POWERED property from AbstractSimpleLogicGate with a static import.
• Modified updateTarget to take a direction as a parameter. It used to use a state, but all it needed was the facing direction. There's a couple other methods that still use states that only evaluate the direction in the multiblocks that should also probably be changed around.
• The methods getSideInput/getCarryInput were able to be made static. Static method calls are free performance for the record, so if it can be helped, tack static onto it.

Last thing, Java class naming schemes follow PascalCase, where the first letter of each 'word' in the class is capitalized. You'll see this in the game code too. The file names of this project are all over the place, some are pascal case, some (the blocks) are a hybrid of pascal and snake_case, and one is screaming at me in snake case (BLOCK_PART). I'd advise for readability and consistency all file/class names be moved to pascal case. If you're feeling lazy feel free to just comment that you're okay with me going through and renaming them, and I'll PR it.

[MMT007]

I think this PR can be closed since #16 contains changes from this PR, and then #16 was merged into main