Fix duplicate calls of certain click events

[sovdeeth]

Description

Fixes a bug where right clicking on an entity can fire a right click event twice.

When you right click on an entity with no block in reach, a PlayerInteractEntityEvent is called like normal
However, a PlayerInteractEvent is also called, with the type of RIGHT_CLICK_AIR.
(This is also the case if there's a block in reach, but the SkriptEventHandler filters out non-air clicks with a useItemInHand value of DENY. air clicks ALWAYS have useItemInHand value of DENY for, like, non-usable items. So those aren't an issue). This causes the following:

on right click: # fires twice
on right click with <item>: # fires twice
on right click on player: # fires once
on right click on air: # fires once

The solution chosen is to combine the PIEE and PIE trackers, so we can only have one event of either type per tick from a player. This solves the issue, but is a breaking change (on right click on air no longer fires when clicking on an entity). Personally, I think this is acceptable, the behavior is technically a bug. The behavior now becomes the following:

on right click: # fires once
on right click with <item>: # fires once
on right click on player: # fires once
on right click on air: # doesn't fire

---

Target Minecraft Versions: any
Requirements: none
Related Issues: #6460

[TheLimeGlass]

#5250 Needs relation investigation.

Do you use ViaVersion?

[sovdeeth]

#5250 Needs relation investigation.

Do you use ViaVersion?

Nah, this is completely separate from ViaVersion, though I bet it's the same issue. (i also don't use viaversion, to clarify).
The behavior sounds pretty much identical to what I'm seeing in my testing without viaversion.

[AyhamAl-Ali]

Good work Sovde ⚡

Is it possible to have tests for this? it seems like it can cause issues without a decent testing since we had this implementation for long time

[TheLimeGlass]

Good work Sovde ⚡

Is it possible to have tests for this? it seems like it can cause issues without a decent testing since we had this implementation for long time

Would need mocking usage, still possible, but over complicated.