Draft: Hud Hooks Version 2

This is a relatively BIG change that touches a good portion of the rendering code and changes the control flow to constantly jump in and out of a function to call other functions, for this reason, I am marking this as a draft until this is a 100% satisfactory solution. I will also have the commits in this MR squashed when accepted in case many more commits are made.

Summary

Essentially, the first system is good, but it still didn't allow for more fine-grained edits and caused issues with the pause menu rendering under edited huds. We went from having to copy the entire rendering code and making the hud code run twice to having to copy the entire rendering code, but now we can disable running the code in the old hook so only the code from our new hook runs.

This new version of the hud hooking system aims to make finer edits to the HUD code a possibility while staying inside the original hud hooks that run all of the rendering code, bypassing the pause menu issue as a bonus. Mods that want to replace singular functions can do so with a single function call and will no longer have to copy over the entire hud code for such an edit.

New Functions

• SRB2P_HaddHook(hookname, funcname, func): Adds a function func under the entry funcname to the table of the corresponding hookname, if funcname is "misc", it will be placed into a special list of functions, similar to SRB2P_Hooks.
• SRB2P_HreplaceHook(hookname, funcname, func): Replaces the function used by the entry funcname in the hookname group with func. This function will fail if funcname doesn't reference an already existing function.
• SRB2P_HrunHook(hookname, funcname, ...): Runs the function stored in entry funcname in the hookname group, providing the function any arguments the runHook function is given. If funcname is "misc", the runHook function will instead act like an SRB2P_runHook call, where it will iterate through the list of functions inside the table, running them in order of addition.

Current Concerns

• There's a possible performance drop that comes with having to call SRB2P_HrunHook for every local function added to the table. With the number of functions that have to pass through the hook now, that could very well be noticeable on computers with weaker hardware. Perhaps a function call via direct table access would be more efficient? This wouldn't apply to functions in the "misc" table, however.
• I'm not 100% sure about the new functions as they are now, SRB2P_HaddHook and SRB2P_HreplaceHook at the end of the day do the exact same thing, just with different checks beforehand relevant to their purpose, should I combine these two and use a more general name like SRB2P_HinsertHook?