[MC-123217] Moving blocks don't inherit behaviors of the block they hold

When moving blocks with pistons they change their behaviors while being moved.
In some - not all - cases it would make sense and remove some bugs if the moving block took some of the properties of the block inside it.

Here is an incomplete list of the properties that could be considered.
Please note that each of these should be well thought about and discussed, as there is also great potential to introduce new bugs.

Behavior	Related Issues	Comment
Light opacity		Can cause flickering and a waste of performance due to unnecessary light updates in flying machines
Solid top	~~MC-93631~~	Could fix Rails popping out on finishing moving, returning solid for the moving block seems odd though, because when it starts moving there is certainly no solid top on the target side
Solid/Transparent block		Would break a well known and used redstone behavior
Visual Transparency	~~MC-158003~~
Slipperiness		Basically just matters for ice, but would make sense
OnFallenUpon Behavior	~~MC-89043~~ (not the same cause)	e.g. slimeblocks should bounce players up while moving
Blast resistance	~~MC-123025~~	Sometimes used to easily break blocks, kind of a cool quirk
Redstone power output		Frequently used redstone behaviour
Emitted light	~~MC-3667~~
3rd person camera behavior	~~MC-233929~~
Sculk sensor vibration blocking	~~MC-213587~~
Block material/note block instrument	~~MC-250307~~
Tinted glass for beacon beam color	~~MC-147777~~	beacons cannot quickly change colors with fast pistons

What else could be considered?

Another option would be to start using the holding block's behaviors once the block moved half the way, but it seems odd and might not be supported by the underlying structure to have changing behaviors without changing the block state like that.

These issues are generally not vitally important, however I think they are worth considering for potential systematic changes regarding moving blocks.