Add signals for InputEventAction to the Input singleton

[qaptoR]

each InputEventAction of the InputMap will add an *_pressed and *_released signal that can be connected to.

additionally an action_toggled signal was added that will fire for all actions that are triggered by an InputEvent

Implements such usability:

func _ready():
    Input.connect('ui_accept_pressed', func(): print('accept action pressed'))
    Input.action_toggled.connect(func(action, pressed): print('%s.pressed is %s' %[action, pressed]))

This PR is made to solve this proposal:
Closes godotengine/godot-proposals#1853

This PR essentially updates the work from this closed PR to bring it into alignment with master:
#43646

That is to say that superficial changes have been made to get it working but the underlying implementation remains the same, and it is in my opinion that the solution constitutes essentially atomic work that could not be significantly changed without causing needless obfuscation.
I am of course, just one person with a biased sense of coding principles and a limited knowledge of all the methods available in the Godot source project, therefore I open this PR in the hopes that it will be merged for the greater benefit of the community, but also to further the discussion about what may need to be changed in order to satisfy the stigma that surrounds the original work.

Some conversation was already had on the dev chat:
https://chat.godotengine.org/channel/devel?msg=n2RaX48Nre7x3CpZC

The general consensus was that the original PR constituted a public distribution in good faith at the time it was authored under the MIT license, and it is thus fair to use. However the question regarding the ship of Theseus does remain unanswered.

[AThousandShips]

Your code has invalid formatting, it needs to be indented with tabs and match indentation, it's good to always use clang-format on any source file you've changed

You also need to run --doctool on the compiled code to update documentation and preferably document the new signal action_toggled

This feature should probably also be documented in Input and/or InputMap and also clarify that this does not work for actions added during runtime, only actions in the project settings or the default actions

[dalexeev]

1. This PR doesn't take into account that actions can be added/removed at runtime using the InputMap.
   • There is currently no way to remove an user signal (see Support to remove, edit and store user defined signals #69243).
2. I'm not sure if adding signals dynamically is a good thing, since such generated signals cannot be documented, they are harder to discover.
   • Also, the GDScript analyzer will not be able to statically infer the type of these signals. Completion will not work with them, lines will be marked as unsafe and UNSAFE_* warnings will be raised if they are enabled.
3. Unlike the _input methods, Input signals are global, you can't mark an action as handled. I would prefer a new callback like _input_action.

[AThousandShips]

That approach would also negate any issue with consent of the copied code etc.

[qaptoR]

My apologies for forgetting to run clang format. I have it installed but it's been over a year since I've created a PR so my wheels are a bit rusty.

I will run those commands before my next push.

This is my first stab at the Input.xml doc for the custom signals:

I thought documenting them here since it is where they are connectable made sense.

EDIT: When I ran the --doctool it only erased the work I had done in the image above... not sure what to make of that, as it didn't generate any documentation for the action_toggled signal

[AThousandShips]

Adding signals that aren't actually in the class won't work with documentation and will cause a ci error

[qaptoR]

Adding signals that aren't actually in the class won't work with documentation and will cause a ci error

I'm assuming you mean that they should be removed, so I will do that.
However I'm not sure how else to document them. Unless what you meant earlier was that it should be documented officially by the documentation team?

[AThousandShips]

It should be documented in the description of Input is what I meant

[qaptoR]

It should be documented in the description of Input is what I meant

You're going to think I'm quite dense for not figuring that out, lol, but it's very practically a core component of why I enjoy programming. I often think in very literal terms, and could not see past 'signals go in the signal section'.
Well I guess there's another force push this morning!

[AThousandShips]

I fully understand, I tend to be very literal at times, and I'm sorry for not communicating that clearly, it's easy to become used to what you yourself know and it can be hard to realize the things that are not obvious if someone isn't experienced with a thing

[qaptoR]

I should probably get some kind of moniker that says 'frequent force pusher', because yes, all of my PR's are like this, it's a curse.

[AThousandShips]

You need to check that the InputMap is created, it isn't always, it isn't when running tests for example, so you need to check that InputMap::get_singleton() returns non-null

[qaptoR]

Thank-you for providing that fix information. I for sure would not have figured that out on my own

[AThousandShips]

No problem! I had to dig a little before I realised why this could happen myself