Add ability to create signal connections that pass arguments as arrays

[PangolinMontanari]

Describe the project you are working on

A turn-based deckbuilding RPG

Describe the problem or limitation you are having in your project

I'm building scripted behaviors for the use of cards on enemy creatures, and in this structure that works by having functions await a signal generated where the player may select from one of many enemies. What this means is that the game itself is awaiting one of several signals generated when the player selects an option- This could include not only an enemy target, but also it awaits an input to cancel this selection(think a 'back button' sort of functionality).
To this end, I have implemented a mediator object to which I can pass an array of signals, combining different signals from different sources, such as signals generated from selecting enemies, from backing-out input, from selecting other options, and so on. But this has presented a problem- it requires all signals to have the same signature. If a signal is emitted with a number of arguments different from what the accumulator expects, it will create an error. While I can change the number of arguments a method receives from a signal, there is no way to detect how many arguments a signal is passing. This is especially problematic with built-in signals where the number of arguments passed is not possible for me to change. In the end, my only option for this accumulator object is to provide multiple redundant functions that account for the possibility of signals having (the same number of) variable arguments.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

My proposed feature would be to add a function parallel to .connect that tells signals to pass their arguments inside of a single array. .connectv could be the name of this function. This would allow the user to create methods that can respond to a dynamic number of arguments or even conveniently discard all arguments a signal sends.
This is especially useful when confronted with the fact that a signal's arguments are not bound to a signature- the number of arguments is determined by whatever arguments the user provides upon emission. For instance, it's possible to have some_signal.emit(1,2,3) and some_signal.emit(1) in the same block of code. This isn't even necessarily a wrong thing to do, if for instance the user wishes to create different behaviors based on conditional code.
The addition of .connectv would not break compatibility, since it does not affect existing functionality, either in callable binding or in vanilla .connect. Rather, it only changes the way that the data sent by a signal is received, and only voluntarily for the callable provided.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

A rather abstract sort of example might be this:

If this enhancement will not be used often, can it be worked around with a few lines of script?

This cannot be worked around in code, since there is no way to check the number of arguments that a signal is providing at runtime.

Is there a reason why this should be core and not an add-on in the asset library?

It depends on core functionality that does not exist.

[Ivorforce]

I think your problem would be better solved by supporting varargs functions in general: #1034

In your case, this would mean the signal would be received like:

func _receiving_function(*args):
    if args.size() == 0:
        return
    [...]