[3.x] Fix routing of InputEventScreenDrag events to Control nodes

[m4gr3d]

Multitouch support enables multiple concurrent InputEventScreenTouch and InputEventScreenDrag events each differentiated by their index property.

An InputEventScreenDrag event typically follows another InputEventScreenDrag or InputEventScreenTouch event and thus should be routed to the target that last matched the previous touch event.
Prior to this fix, in a multitouch scenario only the target of the first touch event was tracked, causing all subsequent multitouch drag events to be routed to that invalid target. The PR tracks the touch targets using the touch event's index property, and use that data to properly route drag events based on their matching index property.

main version

[m4gr3d]

cc @Sauermann

[Sauermann]

Alternative to #34383

[m4gr3d]

@RandomShaper Ping on this PR. It's the same as #68632 for the 3.x branch.

[akien-mga]

Thanks!

[timothyqiu]

Cherry-picked for 3.5.2

[akien-mga]

Cherry-picked for 3.5.2

Reverted with a204af9 to fix regression #70119. We can consider cherry-picking it again if/when the regression is fixed in 3.x.

Edit: #70583 fixes the regression, so it could be cherry-picked. But let's first wait for test reports on 3.6 beta 1 before bringing this change to 3.5.

[dlccmind]

I have noticed that if you have overlapping TextureButtons it is impossible to guarantee that the topmost button is the one that gets clicked. It depends on order in the tree but if you reorder them it still can affect the button below. This is maybe not a common problem, but in my case, making a jigsaw game it is a critical issue. Maybe this problem is related to this one? Just a heads up if you are looking around in this code.