Use ktor instead of okhttp

[rfc2822]

Mainly to get suspending requests so that we don't have to do runInterruptible { } in DAVx5 for every request.

Also we become more independent of the HTTP engine and it's also a step in the direction of supporting more platforms.

Current idea for a steady transition:

1. Test Ktor in other projects and get used to it.
2. At some time, move all existing dav4jvm code into a new at.bitfire.dav4jvm.okhttp package.
3. Create new classes (DavResource, …) based on Ktor in at.bitfire.dav4jvm.ktor.
4. Use that classes for certain purposes in DAVx5, like WebDAV only.
5. When all functionality is available and stable in Ktor, deprecate the old package / remove it at some time.
6. (If it really works on other platforms, the repo could also be renamed then to make clear that it's not only for Android/JVM anymore. However maybe there are still other dependencies that are only available on Android/JVM yet.)

---

Depends on #80

[rfc2822]

CC @patrickunterwegs: related to our last discussion (I'd prefer the way with two packages)

[patrickunterwegs]

Gotcha, I'm not sure if it's a good approach though. While it's okay to make the changes for Android now, it would limit the options once the multiplatform transition is done. Then there would be okhttp code for Android only while still files for all other platforms need to be created that would just not be implemented. That sounds a bit ugly to me.

In any case I am working now on a Ktor version that would just adapt the current code. It would be easy to move the files in a new package and restore the previous ones after anyway.

Let's talk about this again. If you consider renaming the package, maybe it could be better to just create a new library like dav4kmp to use both in parallel.

[rfc2822]

When we finally remove the okhttp package, we should:

• update the README
• remove the "Requires Ktor" comments.

However we need to make DAVx5 working with Ktor first (which will take some time).