Additions to the delay tag

[kristophergeou]

What if we tweak how the <delay> tag works? I'm thinking of having Deluxemenus store delayed actions locally in the plugin, linked to users' UUIDs. This way, when a player leaves the server and comes back online, those actions can be executed. Currently, when a player leaves the server, delayed actions are lost. This sometimes leads to minor issues and requires more complex workarounds, making the delay command a bit challenging for those with limited experience in Deluxemenus. Imagine the scenario:

click_commands:
- [broadcast] &7%player_name% +2000$ in 10seconds
- [message] &7Hello Blitz<delay=100>
- [console] eco give %player_name% 2000<delay=200>

After the [broadcast] command, if the player leaves the server and doesn't return within the next 5 or 10 seconds, there's a risk of losing one or both of the delayed actions. This is where Deluxemenus could step in to store these delayed actions, perhaps in something like:

(player_uuid): 
  - [message] &7Hello Blitz  #When 5 seconds pass aka - 100 ticks
  - [console] eco give %player_name% 2000 # When 10 seconds pass aka - 200 ticks

In the usual scenario, when these actions attempt to execute but the player isn't online, they would instead be stored and executed once the player is back online.

[BlitzOffline]

I have considered this before but I never started working on it because of a few reasons:

1. How long should these actions be stored? Do we still execute the actions when a user doesn't join for a year?
2. What if important stats regarding the player have changed during this time? What if some placeholders return very different values than was expected when the action was first meant to be executed?
3. How do we prevent spam? This question is partially related to the first question.
4. What format do we store these actions in? Do we allow server owners or users with file permissions to edit them? Do we maybe offer commands to allow for the removal of delayed actions?

These are some of the questions that need to be answered before implementing this change.