Fix block placement handler

[Thodor12]

Closes #812

Changes proposed in this pull request

• Use the BlockItem#place method similar logic instead of custom placement logic

Testing

• Yes I tested this before submitting it.
• I also did a multiplayer test.

Review please

[MotionlessTrain]

Could you double check whether anything changed regarding torches which were standing on the block?
Just in case they first managed to stand, but now pop off

[Thodor12]

This is only used during block replacement

[MotionlessTrain]

Yeah, that is what I am talking about
When using this to replace a wall of your building with a lower tier material (when designing a lower level building), it would be annoying to pick up all torches that fell inside, and put them back at the right place
Iirc Structurize has support for that (no pun intended), and I was wondering whether that was this code

[Thodor12]

Oh yeah that'll still be broken but that's impossible to fix because we have to give a block update unfortunately

[MotionlessTrain]

As long as that doesn’t get worse than it is now

[Raycoms]

We shouldn't go over this placement context because this will mess with blocks like stairs, etc as they use hit directions etc which will result in strange things.
Which of these things here specifically do the necessary things for the panels to work?

[Thodor12]

The problem is I need getStateForPlacement, which is what requires the placement context

[Thodor12]

I can do a test with stairs but important is that this is only used by scan tool replaces it looks like

[Thodor12]

And the copy properties method that goes after the placement state should copy the direction of a stair over

[Raycoms]

getStateForPlacement probably translates some meta data into the blockstate property we need. We should be able to get this from the internal call that method uses

[MotionlessTrain]

Just in case, according to documentation (that is, the chat message in game), if you replace a block with another block with similar block states, it should inherit the block states
If the new block has block states that are not present on the old block, the default block state property is used (and the chat message is printed)
Which means, in particular for stairs, if you are replacing one stair with another, it should have the same shape in the same direction, and if you are replacing a non-stair non-shingle with a stair, it should always face in the default direction (north?), independent from how you are standing

[Thodor12]

getStateForPlacement probably translates some meta data into the blockstate property we need. We should be able to get this from the internal call that method uses

There's nothing else for this, check PanelBlock in DO

[Thodor12]

I verified and stairs continue to work normal. Because of:

BlockState newState = copyFirstCommonBlockStateProperties(placementState != null ? placementState : targetBlock.defaultBlockState(), blockState);