Control long_call_time options

[Y-Less]

This introduces script-side control of the long_call_time errors (#76), for example if you know a function is slow and just want to suppress the warning entirely. You can also reset the timing if, for example, you want to know which sub-call is slow in a function that may make lots of calls.

For example, I've just updated YSI:

https://github.com/pawn-lang/YSI-Includes/commit/011ca59b49c65f1d4ead38ca14f16aaa288a898e

During startup, the code generation is very slow, so this disables the warning for that case.

https://github.com/pawn-lang/YSI-Includes/commit/5d6ee138c0f2397fd66fe510d15a60545d82fb3a

During testing one test could be very slow while all the others are fast. This will reset the timing check between every test so that you get a warning for each slow test, not just one warning that all the tests together are slow.

You can also totally disable the long call checks now with:

long_call_time 0

[Y-Less]

[debug] Long callback execution detected (hang or performance issue)
[debug] AMX backtrace:
[debug] #0 00014a60 in public bool:@yQ_y_cell_CountBits3 () at D:\work\SA-MP\pawno\include\YSI_Players\y_groups\..\..\YSI_Core\y_core\..\y_testing\..\y_core\y_cell_tests.inc:594
[debug] #1 native CallLocalFunction () in samp-server.exe
[debug] #2 0000abb8 in bool:Testing_Run (&tests=@028777d8 0, &fails=@028777d4 0, lastfail[33]=@0000e010 "", bool:p=true) at D:\work\SA-MP\pawno\include\YSI_Players\y_groups\..\..\YSI_Core\y_core\..\y_testing\y_testing_entry.inc:465
[debug] #3 0000b904 in Testing_RunAll () at D:\work\SA-MP\pawno\include\YSI_Players\y_groups\..\..\YSI_Core\y_core\..\y_testing\y_testing_entry.inc:789
[debug] #4 0000b01c in main () at D:\work\SA-MP\pawno\include\YSI_Players\y_groups\..\..\YSI_Core\y_core\..\y_testing\y_testing_entry.inc:602
FAIL: "y_cell_CountBits_v4(i) ==  count" (22)

FAIL: "y_cell_CountBits_v4(i) ==  count" (22)

That test shouldn't fail (it hasn't changed in years) and doesn't without the plugin. Plus I repeatedly tried it and it only sometimes fails. So I think somehow the message is interfering. Possibly because those backtraces are normally only shown when code crashes (so won't continue) but this is shown during valid running code that should continue.