Replace SourceHook and CDetour with KHook

[Kenzzer]

In the continuity of alliedmodders/metamod-source#223. This PR strips SourceHook and CDetour from SourceMod.

Marked as a Draft until I finish writing the x86 assembly for dhooks on windows, and I'd like to have some unofficial builds tested around first. Local testing looks good though!

Breaking changes

• SourceMod (SM) 1.13 onwards will only be compatible with MetaMod:Source (MM:S) 2.0+.
• Extensions that make use of SourceHook will fail loading and compilation against SM 1.13 headers will fail.
• Extensions that make use of CDetour only will continue to load but fail compilation against SM 1.13 headers.

Benefits

• DHooks extension finally supports x86_64.
• DHooks plugins can now detour the same function without crashing.
• Various other bug/crash fixes with DHooks.
• Extensions that make use of CDetour and hook the same function will no longer crash.

Those breaking changes are definitively not ideal, and I went in working on this knowing full well the PR might die at the finish line.

In the PR's defense, I have worked on this x86_64 support project (MM:S, SM, KHook) on and off for nearly 2 years, and in that timespan nobody has offered something close to a working alternative. I believe this is as good as it will ever get..

[KyleSanderson]

Are we still concerned about using STL on public interfaces? things will get weird with gcc vs clang extensions.

[Kenzzer]

Are we still concerned about using STL on public interfaces? things will get weird with gcc vs clang extensions.

That's a good point. I've mainly stripped every instances of the word SourceHook without auditing the consequences.

That said, looking at the two interfaces affected IExtensionSys & IScriptManager these two are bridge-only interfaces and don't get leaked to extensions. There's a public header called IExtensionSys.h but it exposes IExtensionManager not IExtensionSys. This can be further verified by the fact the /public dir's includes have not been modified by this PR, and none of the public interfaces make use of STL containers (or sourcehook's for that matter).

Core & bridge are built as a package deal so we probably don't have to worry about diverging STL implems. Unless we want to preserve that flexibility in hot swapping core and bridge libs, in which case I can just bring sh_vector.h into core only.