Migrate PolylinesSerializer to kotlinx-io

[neonowy]

One small step in getting rid of Java dependencies, as noted in #1892 (comment) :)

Just a few things I'd like to get feedback on before finishing this PR:

1. Regarding the new dependency: kotlinx-io is still in alpha, but since the new code is using only a few basic library APIs, any breaking changes are unlikely to affect it? Alternatively, Okio is a more stable option with a nearly identical API.
2. Since no Kotlin library reproduces Java's Object Serialization Stream Protocol used by java.io.Object{Input,Output}Stream classes, this introduces a breaking change to how polylines are stored in the database. How would you prefer to handle it?
   A) Add custom logic for upgrading geometry tables by deserializing existing java.io-backed polylines and then serializing them using kotlinx-io. In the future this would have to be wrapped to be a no-op on non-JVM platforms.
   B) Recreate (DROP+CREATE) geometry tables like it's been done with osm_element_edits.

cc @westnordost

[westnordost]

Cool, thank you for this! I didn't know that a multiplatform substitute for these io classes already existed... albeit in alpha.
Then again, there is no hurry to get this PR merged, so it could just sit here, approved and ready for merge for a while and at the time it makes sense to merge, maybe it is not in alpha anymore, or alternatively, the library gets abandoned and then we use okio directly instead.

Yeah, that Java adds some extra bytes here and there is something I also noticed when I ported https://github.com/westnordost/countryboundaries/ to Rust. It uses Data{Input,Output}Stream on the Java-side now which is really just the raw bytes.

So, I think option 2A) is pretty much out of question because that requires to replicate the Java object serialization stream protocol. I think it would be easier to clear local map data (element geometry + elements) on DB upgrade instead. After all, this is cleared all the time anyway (i.e. old data is refreshed or dropped latest some weeks after it was downloaded)

[neonowy]

Thanks for the feedback! 👍

As suggested, I went with the second option: deleting all elements + element geometry + DownloadedTilesTable (if I understand correctly, the app would otherwise think it still has the map data we've just deleted). Used DELETE FROM as it's just as fast and less lines of code.

[westnordost]

(Just assigning the people who did the work to the completed ticket so that https://github.com/orgs/streetcomplete/projects/1/views/1 looks nicer :-) )