Clean up the extern directory

[Kenix3]

We should not be relying on any external repositories committed into LUS.

Supercedes #500

• dr_libs (Fetch a commit from SHA) remove until we have a need for it in a Ship:: resource
• stb (Fetch from a commit SHA) (blocked by move switch/wii u to forks, remove switch/wii u specific code #485)
• thread-pool (Fetch from tags)
• StormLib (We 100% used to have changes, but I don't think we do anymore. Double check before converting.) (Might need to just fetch from tag) (blocked by: Replace SFileCheckWildCard #442)
• libgfxd (Need to fetch from commit SHA) (may conflict with Don't directly include LUS::GfxDebugger in Ship::Context #521)
• imgui (There are not packages for the docking branch, might need to fetch) (There may be some changes, but it is believed they are Switch specific) (blocked by move switch/wii u to forks, remove switch/wii u specific code #485)
• nlohmann-json (Has all packages we need)
• spdlog (Has all packages we need)
• tinyxml2 (Fetch from tags) looking into package manager
• StrHash64 (Don't know what repo we took this from, if any. Can just absorb the code)
• ZAPDUtils (Remove ZAPDUtils as a dependency on LUS. #484)
• metal-cpp (We don't know where this came from, but worst case it could be absorbed into the renderer)

[briaguya-ai]

see #374 for imgui stuff - i see 2 options for paths forward here

either

• fork imgui and apply our changes from extern there
• pull from sha on fork until move switch/wii u to forks, remove switch/wii u specific code #485
• switch to pulling from upstream sha

or

• keep it in the extern dir until move switch/wii u to forks, remove switch/wii u specific code #485
• switch to pulling from upstream sha

[Archez]

metal-cpp is made by Apple and provided as a download zip from their domain, different versions are listed in their landing page https://developer.apple.com/metal/cpp/

There are some clones of these files on github by various users. I don't know if we want to trust one of these github clones, or pull directly from Apple as a .zip/extract.

It looks like we use the "single header" alternative, which requires executing a python script provided in the .zip to generate the resulting header file.