adds delay checks to input key syntaxes

[sovdeeth]

Description

Adds checks in CondIsPressingKey and ExprCurrentInputKeys to check whether there's a delay prior to the syntax.
If so, it will use the player's current input keys rather than the event keys.

This is only a partial fix for #7388. The bigger issue is that while loops do not take into account their own contents when determining whether to parse the condition as delayed or not. This can't be fixed by simply loading the section before parsing the condition, as the first execution may be undelayed and crucial to the code:

on player pressing of any input key:
    while player is pressing forward movement key:
        wait 1 tick

if we say that the condition is NOT delayed, then it infinitely loops when pressing forward
if we say the condition MIGHT BE delayed, then it will not pass (because it's checking the keys prior to the event)

The prior issue was fixed via use of Delay.isDelayed(), but that has its own issues detailed in #7393. The follow code will never send the "2: " messages:

on player pressing of any input key:
    while true is true:
        player is not pressing forward movement key:
            exit loop
        broadcast "1: %loop-counter and current input keys of player%"
        wait a tick

on player pressing of any input key:
    while true is true:
        player is not pressing forward movement key:
            exit loop
        broadcast "2: %loop-counter and current input keys of player%"
        wait a tick

However, there's no easy fix at this time other than reworking the isDelayed api to integrate structures into the logic, so this works as a stop-gap measure.

---

Target Minecraft Versions: any
Requirements: none
Related Issues: #7388

[TheLimeGlass]

ExprCurrentInputKeys does not need delay checking. setTime already checks for delays at parse time.

[sovdeeth]

ExprCurrentInputKeys does not need delay checking. setTime already checks for delays at parse time.

This is not about parse time checks, it's about runtime checks. SetTime isn't useful here.

[Moderocky]

I think there is room for improvement in this.

[APickledWalrus]

Seems okay. I'm not sure if we actually need to reference the isDelayed (from parse time) state at runtime. It might be more reliable to only check Delay.isDelayed (in case the delay did not actually occur)