Streamline InputEvent class hierarchy to define position property only once

[Sauermann]

This PR changes the InputEvent class hierarchy, so that the position property is defined only in a single new class named InputEventWithPosition. Current status is, that position gets defined in four different classes with their own getters and setters, which would be simplified by this patch. Another benefit is, that this change makes it easy to distinguish between events with and without position.

In order to make this possible, this patch changes InputEventScreenDrag and InputEventScreenTouch, so that they now also inherit from InputEventWithModifiers.

The changed class hierarchy would look like this:

• InputEventFromWindow
  • InputEventWithModifiers
    • InputEventKey
    • InputEventWithPosition (new)
      • InputEventScreenDrag
      • InputEventScreenTouch
      • InputEventGesture
      • InputEventMouse

Implements godotengine/godot-proposals#4158

Bugsquad edit: Related to #55300 and #58334

[akien-mga]

That makes sense to me. I thought about the same but didn't push on that idea since the screen event didn't inherit InputEventWithModifiers. But changing their inheritance to allow this makes sense.

[akien-mga]

I wonder why this is changing in this PR.

[Sauermann]

I asked myself the same question, but could not find any reason for this.

[Sauermann]

Two additional thoughts came to my mind:

• After this change, InputEventWithModifiers is the only class, that inherits directly from InputEventFromWindow. Should they be kept separate?
• After this change, InputEventGesture is an empty class, that is used only in a few locations within the source code. Would it make sense to remove that class?

[groud]

On my side I am not sure about the usefulness of this.
Making InputEventScreenDrag, InputEventScreenTouch and InputEventGesture extend InputEventWithModifiers does not seems to solve a real-life use case, as tactile input and keyboard, are usually used separately.

Also, I think making a common InputEventWithPosition class is not really useful beside the fact it allows reducing a little bit duplicated code. In general, having the possibility to manipulate objects using such an abstract class should help, but in that case, all are quite different events that will need to be handled very differently anyway. This limits the amount of code you could share for all those events.

To sum up, I believe the gain from this PR is limited while it make the class hierarchy more complex (which is visible to the end user, not only internal).

[Sauermann]

@groud regarding real-life use cases, I just made an argument here: godotengine/godot-proposals#4158 (reply in thread)

[groud]

Well, from what I read is that his PR would only help to solve an internal implementation small issue. So this is a contributor's problem, not a user's one. So IMO, this is not sufficient to justify a change there.

Also, regarding your issue, you should check for the first class, and not rely on "set_position". It really unlikely we are going to add a lot more of new events with position anyway, so there's no need to change the class hierarchy just to future-proof that.

[Sauermann]

This was discussed in the PR-review-meeting.
In the future it may be a reasonable change for combining different mouse-similar event types, however not at the moment.
Because of merge-conflicts I am closing this, since it would have to be rewritten in any case.