Allow redirection of lcf console messages

[Ghabry]

First commit: The chunk dumping during Skip didnt really work except on Windows. I finally fixed it (useful for Maniacs Patch to find unknown chunks). Also is now always on, a missing chunk is now always a bug because we know about all common ones.

Second commit: I want your feedback here. Before I implement this completely (is some work) please tell me if the general approach is fine for you.
I want to allow custom output handlers for lcf diagnostics. E.g. for the Player they could be written to easyrpg_log.txt. Currently they are completely lost which is bad for handling bug reports. As vital information is missing.

To redirect it library users can invoke lcf::LogHandler::SetHandler(Handlerfunctionhere)

[fdelapena]

There's a good chance to add more levels, such trace, info, notice, while critical, alert, emergency feel a bit unneeded.
At least those for matching not just with Player, but cover at least the levels existing in JavaScript's console.xxx() (debug, log [which level to use here? default to unclassified stdout?], info, warn and error). Emscripten shell currently uses console.error() for everything but this is easy to fix and helps a lot to filter details from the browser developer tools.

Update: severity levels exists in Player already, so matching with them makes sense nowadays.

[aleck099]

Why are exceptions disabled in liblcf?

[Ghabry]

Same reason why we disable RTTI:

Portability. We have some quite low spec homebrew platforms that we support.
They are low on memory and load the executable into memory so every kilobyte counts.
Also exceptions are also not well supported in emscripten.

We also do not want to maintain two codepaths. So no exception it is.

[aleck099]

But is printing to stderr a good choice?

[Ghabry]

Uhm no that is why I plan to make this configurable in this PR?

Currently errors land on stderr.
With this PR consumers of this library (e.g. the Player) can hook it into their logging system (which logs into easyrpg_log.txt)

[aleck099]

Looking forward to begin merged

[Ghabry]

I rechecked the code now: There is literally nothing finished here yet. Except for one example usage. Can't finish this for 0.8.0 in such short time.

Hot candidate for 0.8.1

[carstene1ns]

I think on liblcf side is not much missing anymore. The handler function concept is well-known and works. Usually you get some void *userdata context to pass, which we maybe should make available for custom loggers.

[Ghabry]

Suitable logging function for use in Player:

lcf::LogHandler::SetHandler([](lcf::LogHandler::Level level, StringView message, lcf::LogHandler::UserData) {
    Output::Debug("lcf ({}): {}", lcf::LogHandler::kLevelTags.tag(level), message);
});

So currently only written to terminal/logfile.

Not sure if any of the stuff should be reported through the graphical "console" inside the window. Most of that stuff is recoverable (similar to the libpng warnings spamming the shell) and everything critical is already shown as an "Output::Error".

[carstene1ns]

I find it a bit messy that at first every log message is made a C-String, then a C++ std::string and last a string_view.
Maybe we should make fmt a lcf dependency in the future to hide the conversions.

Apart from the minor nits, LGTM

[carstene1ns]

Android (clang) build fails with -Wformat-security:

Log::Debug("%s", ss.str().c_str());