Add support for `OSLogStore`

[dfabulich]

https://github.com/dfabulich/skip-oslogstore

This module provides a compatibility API corresponding to Apple's OSLogStore API, allowing app developers to read the OSLog messages from their own app.

On iOS, SkipOSLogStore simply re-exports OSLog. On Android, SkipOSLogStore executes logcat directly on the device, and parses the logs using protobuf-javalite.

[marcprux]

Very interesting! I didn't know an app was allowed to launch logcat (seems like potential security/privacy issue; is there anything stopping it from reading another app's logs with the -p parameter?)

Does OSLogStore.getEntries() return a finite or infinite sequence? Seems like AsyncSequence would have been a better fit for that API at first glance, but that's obviously out of our hands. I do wonder, though, if our getEntries might be better off returning a lazy sequence, both in terms of latency and memory use.

I wonder if this package (or some variation) could act as a wholesale replacement for our simplistic typealias Logger = SkipLogger in https://github.com/skiptools/skip-foundation/blob/main/Sources/SkipFoundation/Logger.swift, which was never a great fit for skip-foundation, and we could add special treatment for it with our import processing, like we do with our other moduleNameMap handling like import AVKit -> import SkipAV.

[dfabulich]

Very interesting! I didn't know an app was allowed to launch logcat (seems like potential security/privacy issue; is there anything stopping it from reading another app's logs with the -p parameter?)

Yes, the OS only allows you to read your own process's logs.

Does OSLogStore.getEntries() return a finite or infinite sequence?

Finite.

Seems like AsyncSequence would have been a better fit for that API at first glance, but that's obviously out of our hands. I do wonder, though, if our getEntries might be better off returning a lazy sequence, both in terms of latency and memory use.

I think that would keep the Process alive longer…? It's not clear whether that's better/worse. Either way, our implementation could return a sequence.

I wonder if this package (or some variation) could act as a wholesale replacement for our simplistic typealias Logger = SkipLogger in https://github.com/skiptools/skip-foundation/blob/main/Sources/SkipFoundation/Logger.swift, which was never a great fit for skip-foundation

I'm not sure I follow your meaning. Everybody needs a logger, but not everybody needs a protobuf library to parse their own logs. (Otherwise I'd have filed this as a skip-foundation PR.)

we could add special treatment for it with our import processing, like we do with our other moduleNameMap handling like import AVKit -> import SkipAV.

Special treatment is cool, but, for my taste, special treatment isn't that big a deal when the Skip packages re-export with @_exported import