Use capabilities to declare incompatiblities between modulesThis commit changes the dependency metadata rules to use capababilities when it makessense. Capabilities can be used to declare that two modules are providing the samefunctionality, so it's illegal to have them both on classpath. In this case, we chooseone module over the other. However, in some cases, we want to always use the newercapability provider, even when there's no conflict, so there are two possibilities:- `select()` will "soft choose", just in case of conflict- `forceUpgrade()` will always replace a dependency with the preferred providerIn general, `select()` should be enough, but there are limitations. For example, wecan explain that `org.ow2.asm:asm:6.1` provides `asm:asm:6.1`, and that `org.ow2.asm:asm-tree:6.1`provides `asm:asm-tree:6.1`. In this case, if the dependency graph contains:- `asm:asm-tree:3.1` -> `asm:asm:3.1`- `org.ow2.asm:asm:6.1`Then we will automatically upgrade `asm:asm:3.1` to `6.1`, but _not_ `asm-tree`, becausethere's no conflict for this module. As we cannot guarantee it's a compatible combination,we forcefully upgrade all modules of "ASM" to the same version.Technically, this feature relies on the "capabilities" feature of Gradle 4.7. Since no externalmodule declares any capability, we need to do 2 things:1. use rules to declare the capabilities for external modules2. fix the conflicts when they happenWe chose to automatically generate a synthetic capability for all modules that provide the samecapability, and rely on automatic upgrade to fix the conflicts. For example, if modules `A`, `B`and preferred module `C` provide the same capability `cap`, then:- `A` is assigned capability `cap` version `1`- `B` is assigned capability `cap` version `2`- `C` is assigned capability `cap` version `3`This way, when `A` and `B` are in conflict, we will prefer `B`. When `B` and `C` are in conflict,we will prefer `C`.