Provide official support for `dagger-reflect`

When using dagger-reflect and not applying the kapt gradle plugin at all, seeing clean builds that take 54% less time for a large app build, incremental builds that take 33% less time.

Similar to how Moshi supports both code-gen and reflect versions, it would be great if the Dagger team provided official support for dagger-reflect to make sure it keeps functional parity with dagger code gen and to make dagger-reflect work with Hilt.

[vRallev]

These modules using the Dagger annotation processor build up to 66% faster now. Stub generation + Kapt are gone, javac becomes a no-op because we generate Kotlin code (the table contains 2 pure java modules, that’s why the number isn’t 0). Kotlinc takes more time.

| Stub generation | Kapt | Javac | Kotlinc | Sum :— | —: | —: | —: | —: | —: Dagger | 12.976 | 40.377 | 8.571 | 10.241 | 72.165 Anvil | 0 | 0 | 6.965 | 17.748 | 24.713

For building entire applications we measured an average saving of 16%.

[Chang-Eric]

I think this is something we can consider, but it is a large commitment to support an essentially second implementation of Dagger, so it isn’t a decision that can be made lightly. I think also complicating that is that the official advice around using it would have to be quite nuanced. For example, something like use this as you develop, maybe in some tests, but also you probably want to run your tests with regular dagger just in case there is some variation.

This is in addition to the two flavors of Dagger code generation that we already support (regular and fastInit) and it looks like there are also two modes for dagger-reflect, so this could add to potential confusion and definitely adds to maintenance difficulties.

So I think this is a good suggestion, and we will keep this issue open, but the decision will probably take some time. As @bcorso mentions above too, we may want to evaluate this against the work to be done to support KSP and see how much of a benefit this will have over that as well.