move addDelayedEvent to trigger after the delay finishes

[sovdeeth]

Problem

Delays would trigger isDelayed as soon as they scheduled the delayed task, rather than when the delayed task begins. Since isDelayed cannot differentiate between Triggers, this meant that one trigger could schedule a delay and a second, undelayed, trigger would think it was delayed too!

on jump:
  send isDelayed # sends false
  wait 1 tick # adds to DELAYED
  send isDelayed # sends true

on jump:
  send isDelayed # uh oh, this ran after the first event, so the event's already in DELAYED! returns TRUE
  wait 1 tick
  send isDelayed # sends true

This PR does NOT fix this issue! It simply mitigates the issue so that the user isn't impacted by it. The delay api still needs to be updated when proper runtime context is implemented.

Solution

Moving the addDelayedEvent call to after the delay is complete ensures that non-delayed code can run as normal, but still ensures delayed code is ran as delayed code. I believe this is safe, but if anyone can think up a counterexample please comment it.

Testing Completed

Manual testing confirms this functions properly, but I did not do a comprehensive check of behaviors. Automated tests can't handle delays so this can't be tested automatically.

Supporting Information

---

Completes: none
Related: #8298