Implicit waitstate for special/specialvars

[mrgriffin]

special and specialvars that are always followed by a waitstate now implicitly generate that waitstate when called. This should make it easier to use those specials for newcomers who have not internalized "a UI special needs a waitstate after it to stop the script progressing to a disastrous result".

If an implicit waitstate is immediately followed by an explicit waitstate the second one is ignored and a warning is reported, thus making the change harmless for downstream projects (if a little noisy). If there are other instructions between the implicit and explicit waitstates then both are generated, which would manifest as a softlock; I think writing code like that is unidiomatic, so hopefully this will not affect (m)any downstream projects.

The candidate specials were mostly identified with the following: git grep -B1 waitstate data | grep -v '^-' | sed 'N;s/\n/ /;p' | grep -o 'special [a-zA-Z0-9_]*' | sort -u.

Notable specials that are not always followed by waitstate are EnterSecretBase, RunUnionRoom, and ShakeCamera. Of these, ShakeCamera is particularly disappointing because 22/24 of the uses are immediately followed by waitstate. In the future we could consider extending special to support this use-case.

Discussed in the pret and rh-hideout Discord servers.

[mrgriffin]

Wrote a script to automate the deleting of any explicit waitstates that report a warning: delete_implicit_waitstates.py. Usage python3 delete_implicit_waitstates.py. MAKES CHANGES TO YOUR WORKING DIRECTORY, COMMIT YOUR CHANGES BEFORE RUNNING.

I reverted the changes to data/ (except data/event_scripts.s and data/specials.inc) from this PR, ran the script, and ended up at the same state as this PR is is.