Replace reflective backend with kotlinx-metadata-jvm

[oharaandrew314]

This backend is lighter and faster that kotlin-reflect, so it should reduce the footprint of this module.

[oharaandrew314]

I've made progress with this, but migrating from a KConstructor to a Constructor is tough.

[adampoplawski]

Hello @oharaandrew314
Just wanted to ask if you still trying to solve it. We have some requirements when we are using GraalVM so kotlinx-metadata-jvm would be very beneficial for us.
Thx for your support

[oharaandrew314]

No, I'm not actively working on it anymore. It's quite difficult to build the data class constructors without the assistance of kotlin-reflect. For instances where I need to avoid kotlin-reflect, I use http4k-connect dynamodb, which can be configured to map the document with a generated JSON adapter (via kotlinx-serialization or kotshi), which is even faster than kotlinx-metadata-jvm anyway. It's a pretty advanced maneuver that needs better documentation, but I've at least covered it in a video.

For what it's worth, both kotlin-reflect and kotlinx-metadata-jvm use reflection. I was under the impression Graal could be configured to retain reflective capabilities with some configuration.