[FR]: Many unwanted build variants are created because of `AndroidLibraryConventionPlugin`

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Describe the problem

The convention plugin [AndroidFeatureConventionPlugin](https://github.com/android/nowinandroid/blob/main/build-logic/convention/src/main/kotlin/AndroidLibraryConventionPlugin.kt) currently creates many unwanted build variants, which definitely has a negative impact on total build time.

https://github.com/android/nowinandroid/blob/b91773d05358fee6cbc64bc9de90817522399a3d/build-logic/convention/src/main/kotlin/AndroidLibraryConventionPlugin.kt#L43

This creates variants of libraries, where in fact, they are meaningless and detrimental because the code is always the same, and it forces consumers to be "variant-aware".

For example, the `:core:domain` module which **should not** have variants:

```bash
> ./gradlew :core:domain:tasks --group=build --quiet

------------------------------------------------------------
Tasks runnable from project ':core:domain'
------------------------------------------------------------

Build tasks
-----------
assemble - Assemble main outputs for all the variants.
assembleAndroidTest - Assembles all the Test applications.
assembleDebug - Assembles main outputs for all Debug variants.
assembleDemo - Assembles main outputs for all Demo variants.
assembleProd - Assembles main outputs for all Prod variants.
assembleRelease - Assembles main outputs for all Release variants.
[...]
compileDemoDebugSources
compileDemoDebugUnitTestSources
compileDemoReleaseSources
compileDemoReleaseUnitTestSources
compileProdDebugSources
compileProdDebugUnitTestSources
compileProdReleaseSources
compileProdReleaseUnitTestSources
demoDebugSourcesJar - Assembles a jar archive containing the sources of target 'demoDebug'.
demoReleaseSourcesJar - Assembles a jar archive containing the sources of target 'demoRelease'.
extractDemoDebugAnnotations - Extracts Android annotations for the demoDebug variant into the archive file
extractDemoReleaseAnnotations - Extracts Android annotations for the demoRelease variant into the archive file
extractProdDebugAnnotations - Extracts Android annotations for the prodDebug variant into the archive file
extractProdReleaseAnnotations - Extracts Android annotations for the prodRelease variant into the archive file
prodDebugSourcesJar - Assembles a jar archive containing the sources of target 'prodDebug'.
prodReleaseSourcesJar - Assembles a jar archive containing the sources of target 'prodRelease'.
```

### Describe the solution

Remove the default "flavoring" of `AndroidLibraryConventionPlugin`, and centralize it in a dedicated `AndroidFlavorsConventionPlugin`.

### Additional context

This also brings the question of "where" should `@Module` be declared.
For instance, in the `:core:analytics` module, we have the modules defined in the variants sourceSets (prod/demo). Even though the stub (for demo) and Firebase (for prod) is shipped in the main/default sourceSet which breaks the expectations of build variants to only contain the relevant code.
Having this module publish its variants, forces other modules dependending on it to also be variant-ware...

Here are two solutions:
- (simpler) move the `@Module`s to the `:app` module, which is meant to be variant-aware.
- (more "correct") move the `@Module`s to a `:core:analytics:wiring` module, which only the `:app` module will depend on.

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

Start in build-logic/convention/src/main/kotlin/AndroidLibraryConventionPlugin.kt, especially the referenced flavor configuration, and inspect the tasks for :core:domain to understand the unwanted variants. Review the prod/demo sourceSets in :core:analytics and the proposed app or :core:analytics:wiring destinations for @Module declarations. Done means libraries no longer publish meaningless variants while the app retains the required flavor behavior.

Written by the indexing model from the issue text.