hook.runRemote fix w/ cpuTime recursive runWithOps system.

Will Fix #362

runRemote will now return multiple results if multiple remote hooks are defined. runRemote wrapping issues are now fixed If an empty result is given ( from a chip not having the hook defined? ), then it is simply ignored.

Return structure from runRemote is now a table of tables. Each first key represents a responding SF chip with a remote hook defined. These then in turn return a table of their results ( as you can return multiple values ). Eg return 1, "alpha" would show up as { { 1, "alpha", } }. With a second defined SF remote hook returning something, the results table would look like: { { 1, "alpha" }, { 1234 } }.

Upon fixing runRemote several other bugs came through. Notable that during runRemote we call runWithOps on a remote instance. This would then fail as the sethooks would 'decouple' (?) ( set to nil ), then we'd run away without any ops checking at all!

This is fixed by adding in a simple, global based, counter. As Lua is single threaded and executes all chips sequentially, despite it appearing in parallel. This counter keeps track of the number of 'scopes' / 'recursions' that set hook as gone through and will only remove the sethook when we're in the outermost 'runWithOps' call. Likewise, it will only ever 'set' the hook onto the wrapperfunc if we're in the outermost, just for the sake of correctness.

This implements a new table SF.Instance.sethook, containing counter, the number to track, and 2 functions, set and clear for setting the debug.sethook when counter is only 0.

NOTE: If the caller SF chip executes a function defined in a remote hook from the defining SF chip, which contains some form of throw/error. The calling SF will error, but the error message will blame the defining SF chip. This is because the blame level is incorrect; however, the only fix for this would be to malform the traceback in search of some other 'SF' level to blame, which may result in unreliable erroring. This would also have to be global change to how all erroring works. For now, it is not that major a problem.

INPStarfall / Starfall

hook.runRemote fix w/ cpuTime recursive runWithOps system. #395