Expose Godot signals to map editors

[Shfty]

Use the same property types that drive Quake's target/targetname setup? Need to expand it to arbitrary signals and slots if possible, but the FGD spec makes it sound like it's designed around a 1:1 target/targetname relationship a-la Quake.

Could use target/targetname to determine entity relationship, plus additional properties for defining multiple signal/slot pairs?

[Shfty]

A somewhat advanced version of this is implemented in the latest commit.

Unfortunately TrenchBroom doesn't support target_destination and target_source in a general manner- it's hardcoded to use the Quake-style target and targetname keys for entity link visualization.

So for usability's sake, signals and slots are represented as point entities that store signal and slot names respectively, and form a target -> targetname chain from the entity broadcasting the signal to the entity/entities receiving it in a slot. Each step in this chain can be one-to-many, so the emitter can target several signal objects that share a targetname, which in turn can target several slot objects that share a targetname, which finally can target several entities that share a targetname.

This signal/slot relationship is fixed up during build by QodotMap, and the signal/slot entities are then deleted since they're marked as transient in their FGD definitions.

This works very well, but is a bit complicated for simpler Quake-style workflows that have a universal 'trigger' and 'use' setup. Need to add a type check to connect_signals that falls back to a simpler 'connect the trigger signal to the use slot' behavior to allow for direct entity-to-entity connections.

[Shfty]

A simple trigger -> use signal/slot connection has been implemented in the latest commits.

If an entity has a valid target field and a signal called trigger, it will be connected to the use slot in its target entity during build.