Refactor k_stdlib to separate hooks from 'sdk' headers

[Meatball132]

I've been working on a project based on the headers from NSMBW's decomp. One of the most annoying issues I've run into is Kamek's own SDK headers conflicting with the ones from the decomp. I've had to modify the NSMBW headers to be compatible with Kamek. That's really annoying, especially when it comes to keeping them up to date etc.

It would be better if those Kamek SDK headers were optional, rather than forced. It's nice to have them for smaller self-contained projects, but when you're reusing headers from other projects (which is becoming more and more standard as the decomp scene progresses), k_stdlib turns into an obstacle. After speaking with others, I've discovered they had their own workaround, which is arguably worse: they're modifying k_stdlib itself to disable these headers. No matter how you deal with this issue, you're currently stuck having to pick your poison.

This PR refactors k_stdlib to solve this problem like so:

• The header kamek.h only includes the hooks, none of the extra SDK headers. The hooks now live directly within kamek.h, as opposed to being brought in from a separate header, seeing as they're the only thing there. This also makes it match with kamek_asm.S.
• The base directory has been renamed to k_sdk to avoid conflicts with other libraries. The name "base" is too generic, and it's also not very fitting anymore since the main Kamek header no longer includes anything from there. The name k_sdk specifically was chosen to mirror k_stdlib.
• For the same reason, nw4r.h and egg.h have been moved into k_sdk.
• The typedefs that were originally in kamek.h have been moved to a new types.h inside k_sdk. This lets them be included individually as desired.
• A new header, kamek_sdk.h, was added to automatically include the headers no longer included by kamek.h. This is mainly for backwards compatibility; it's easier to add a single #include directive to old source files as opposed to trying to figure out which specific headers are needed where. This can also benefit tiny projects that rely on k_stdlib for the SDK and don't want to add a bunch of #includes.

Example patches, as well as the loader, now include kamek_sdk.h as needed.

[Meatball132]

By the way, I feel the need to pre-emptively defend this PR a bit. It was pointed out to me that you could have always just included hooks.h to bypass all the extra stuff, but even though that does work I kind of see that as a hack that wasn't ever intended, given how the library was structured.

It is true that this could be refactored in a way that doesn't break compatibility with projects that rely on the SDK, e.g. by making a kamek_hooks.h that skips including everything. But I'd rather go back and update all my older projects than put up with what is, in my eyes, a subpar compromise in every future Kamek project ever for the sake of blind "backwards compatibility" - and for what? The projects that depend on this part of Kamek are vanishingly small, and I'm personally familiar enough with most of them that I can guarantee they can and will be updated with minimal effort. The header that is used most often should have the shorter filename, and that's kamek.h.

Additionally, I consider the current iteration of Kamek to be an unfinished application with low adoption, and I think that makes this change acceptable. A handful of necessary features and a single standout project that depends on Kamek that will get it mass adoption keeps it from being "complete", and we're (hopefully) fast approaching the moment all of that actually happens. Until then, I think of Kamek as a work in progress that should be iterated on with, yes, breaking changes. This is the time to make this kind of change. While it barely impacts anyone, and in time for new users when Kamek reaches a broader userbase. It is strictly better than the other options. I promise it's worth it.