Make paparazzi aware or unit test dependencies

[alyssoncs]

I'm having a problem on a project where I have a module that contains composables, those composables depend on a IconProvider interface, this interface outputs @DrawableRes Int. We do not want the UI module to depend on the implementation of this interface. But we do want this implementation available on unit tests.

We currently add a testRuntimeOnly (could also be a testImplementation) on this interface implementation and get running espresso tests. But we get weird errors with Paparazzi. Looking into the code, it looks like the dependencies added on the test source set are not added in the Config class by PaparazziPlugin.

This PR is my attempt of making Paparazzi aware of resources of local modules and external libraries that are only visible to the test source set.

I have a proof of concept of a composable depending on an interface, and this interface being provided only on the unit tests (it is also provided on the debug variant to make @Previews work). Running ./gradlew :poc:ui:testReleaseUnitTest should fail.

I also have the same proof of concept + the code in this PR, and the same task succeeds.

This is my first time contributing to this project, let me know what you think of this. Also, does this deserve a new unit test? I could use some help on this. What would be important testing here?

[TWiStErRob]

What would be important testing here?

The issue you're fixing, you can write a failing unit test (gradle project fixture) that only passes if the Paparazzi Plugin has the right wiring.

[alyssoncs]

What would be important testing here?

The issue you're fixing, you can write a failing unit test (gradle project fixture) that only passes if the Paparazzi Plugin has the right wiring.

Added a module that adds both a testImplementation and testRuntimeOnly on two other modules and tested that the resources were included on the generated Config class.

[jrodbx]

I apologize for not giving this a proper review, I intend to do so (finally!) by end of this week.

However, I want to share an early concern about changing this to testImplementation, doing so implies that this is meant to remain a testing library, which currently it is. But we're moving to SDKify this and use this for more than that, so it's by intention that we haven't changed that configuration.

I intend in my review to show what alternative solutions exist to your problem (thank you for the proof-of-concept, btw, it always helps!). Stay tuned.