Event input handling

[nsensfel]

In games where the narrative isn't what drives the gameplay, the narrative is likely going to be called upon following an event occurring from some other mechanism (e.g. "attacked monster A").
Tonkadur makes scripts that expect its execution to continue until the game engine has to be prompted for an input (prompt_string, prompt_integer, player_choice). Technically, the event instruction can be seen as a way to give back control to the game engine, since it expects the game engine to perform something before continuing.
However, games not driven by the narrative are likely to want to have a narrative script running some initialization, keep an internal state, then react to incoming events.
To handle this, player_choice can be used, with the events corresponding to labels. However, player_choice labels are text, whereas coding the interpreter to handle incoming events would make the use of string labels more appropriate. Furthermore, these "choices" would not be expected to be seen by the player, making the interpreter more tedious to implement (special text effect that hides a choice, most likely).
To make narratives that can be driven, instead of having the narrative being the gameplay orchestrator, player_choice should be modified.

(event_input
   (
      <player_choice_list>?
   )
   <event_list>*
)

• (player_choice <player_choice_list>*) becomes a shorthand event_input.
• three types of event inputs: declared events, wild text labels, and globally defined events.
• Using a first-level instruction, (declare_global_event {label=string} {sequence_name=string}), a string can be associated to a parameter-less sequence. This event is automatically added to every event_input instruction.
• declared events: first-level instruction to declare/define the event's string label, but has to be explicitly listed in the event_input to be usable. This is to ensure the events are properly defined.
• Wild text labels: no prior declaration of the string label for this type of event.

TBD: parameter passing for events. For example: "attacked monster A". "attacked monster" is likely to be static, but "A" is an identifier, which is something the narrative needs to be able to retrieve.

[nsensfel]

• (option (<RICH_TEXT>) <INSTRUCTION LIST>) for what currently is a player_choice entry.
• (event ({event_name:String} <C0:COMPUTATION> ... <CN:COMPUTATION>) <INSTRUCTION LIST>) for actual events.
  Wyrd would still only expect the index of the chosen entry to be returned by (get_last_choice_index), so the event parameters must be stored in the available choices, making them slightly harder for the interpreter, as they would no longer just be RICH_TEXT entries, but may also contain some "event name + parameters".

[nsensfel]

Globally defined events are still not implemented, but the rest has been added in 1616f97.