AK+Everywhere: Yeet some libc includes

[DanShaders]

I feel like there is a general consensus that we are not supposed to use libc (either Serenity's or host) APIs in C++ code. Despite that, we include libc headers in each and every compilation unit. Unsurprisingly, this leads to accidental uses of C definitions even when C++ alternatives are available. The most notable example of this is INT_MAX family of macros. So, the PR aims to remove some of the libc includes in AK. It addresses 9 includes that do not match /(AK/|Kernel/)/ and leaves 28 for future patches.

Most of the commits are straightforward to review and are not controversial. initializer_list and AK/Types.h commits, on the other hand, are controversial. I would like some opinions on whether the proposed solution is the right one.

For the AK/Types.h, I investigated using code generator approach instead of guessing. First, it was not trivial to persuade CMake to generate something for AK. Second, it won't work when cross-compiling not for Serenity, since we need to use target libc in generator.

[BuggieBot]

Hello!

One or more of the commit messages in this PR do not match the SerenityOS code submission policy, please check the lint_commits CI job for more details on which commits were flagged and why. Please do not close this PR and open another, instead modify your commit message(s) with git commit --amend and force push those changes to update this PR.

[DanShaders]

The only thing I did with force push is added Fuzzers: Do not use uint8_t (to fix CI error here). The rest of the commits are untouched, so it shouldn't affect jakt more than is currently being tested.

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[DanShaders]

Here we go again

[DanShaders]

Giving up on this :) It requires too much time to keep up to date for the amount of additional value it provides.