Remove kotlin-inject

[vRallev]

Metro is the recommended dependency injection solution. kotlin-inject-anvil is in maintenance mode. There is no reason for someone to use kotlin-inject over Metro except for legacy reasons.

[JessalynWang]

I'm in agreement that Metro is the preferred DI framework, but I'm not sure we should remove kotlin-inject just yet. It is known that heavy consumers of App Platform are also users kotlin-inject, and aside from kotlin-inject not being our recommended default and KIA being in maintenance mode, I'm not to clear on the other reasons to remove the support at this time. For example, do we believe that the overhead supporting code gen for kotlin-inject is now too high? I think it is fine for the metro support to be richer as time goes on, and I don't know if we're at a time where supporting kotlin-inject is causing us a lot of problems.

I'm also not fully convinced that App Platform should ever only support one recommended DI framework. I feel like it should be up to the consumer to choose (with their own use case in mind) from some options that we are able to reasonably support. Pure import changes are one thing, but I think it's understandably hard to switch something like a DI framework. So if there are no technical or bandwidth reasons we cannot support, we can keep it for now.

[vRallev]

Two downsides:

• Maintenance overhead, also in terms of running tests, formatting the code and giving guarantees that things still work. While KI and KIA barely move, Kotlin and KSP change under the hood. I feel less and less comfortable to "support" something in App Platform I'm not using myself. The issues for KI keep piling up and the last change was 6 months ago. I cannot help to see that the project is kinda dead.
• It's not just codegen. Modules like :renderer:public enable both KI and Metro to provide necessary bindings for both frameworks. This could only be avoided by splitting the module into two public modules, something I don't like. That means even though KI is never enabled in a consumer project, KI ends up on the runtime classpath.

I'm not opposed to providing support for other DI frameworks, but I don't see a future for KI (and with that KIA). Projects can bring their own DI framework if they like, nothing is stopping them (similar to how we used Dagger initially before moving to KI).