Sleeping/Impure overrides incorrectly prevent checking rest of call graph

[fira]

Vaguely similar to #247 and likely linked, but specific enough that it really looks like an implementation bug

Consider the following file:

/datum/proc/do_things()
        set SpacemanDMM_should_not_sleep = 1

/datum/proc/thing()
        do_complicated_thing()

/datum/sub/do_things()
        thing()

/proc/do_complicated_thing()
        usr.client.SoundQuery()

This works as expected:

onefile.dm, line 8, column 21:
error: /datum/sub/proc/do_things sets SpacemanDMM_should_not_sleep but calls blocking proc /proc/do_complicated_thing
- 3:2: SpacemanDMM_should_not_sleep set here
- 9:2: /datum/proc/thing() called here
- 6:2: /proc/do_complicated_thing() called here
- 12:12: client.SoundQuery() called here

Now strap at the end funny hijack proc, on a different subtype:

/datum/zzz/thing()
        sleep(10)

Result:

Procs analyzed: 5. Errored: 0. Builtins: 335.

============================================================
Analyzing proc override validity...

============================================================
Analyzing proc call tree...

============================================================
Found 0 diagnostics

Funny huh? In our real world example, this was even more awkward from the fact this still generated a warning, that was also ignored by the same override setting waitfor=0

[fira]

after testing looked to me like an oversight of visiting in check_proc_call_tree - the different checking blocks probably shouldn't be exclusive. otherwise you can get into a situation where there are sleeping overrides, so rest of call graph is not checked, but because all the sleeping overrides were actually relevant to a different sub-type this still isn't a fatal error and silently ignored. something similar also happens with waitfor as mentioned above, and just the general assumption regarding (intended or not but effectively) stopping on error.