Investigate switching from XCGLogger to OSLog as a logging backend

[nbrooke]

We'd investigated this and rejected it when originally creating Steamclog for two reasons:

• It didn't support any way to programatically fetch logs, which meant getting more detailed logs out of the system later (in the manner of the file support now) was impossible
• The expected use case is to call os_log directly from your code, which causes various problems with Steamclog's desired interface of per log level wrapper functions and with forwarding logs to Sentry.

However, because the first problem made it a no go, we didn't really investigate what the ways around the second problem were or what problems were caused if we DID do wrappers.

The first problem has apparently been fixed as of iOS 15: https://steipete.com/posts/logging-in-swift/, so it might be worth a bit of investigation of the second problem to see if OSLog would be a more suitable backend now. The main advantages would be:

• Probably quite a bit more efficient than the current logging
• Would simplify collecting logs from dependant libraries if they also migrate to os_log (no need for logging delegates to forward things out of the libraries)
• May be able to get some portions of the system logs when doing detailed log captures
• Reduces the third party dependancies for a pretty core piece of technology.