Provide a dependency mutual exclusion check

[plaird]

We have found internally that the springboot rule is a good enforcement chokepoint for catching errors in the dependency graph. the dupe class checker gets a lot of mileage and has caught a number of mistakes for us.

Another check we would like to have is fail if mutually exclusive dependencies are on the classpath (configurable in the workspace as per #78). The reason is we have seen cases where the service owner ended up with mutually exclusive libraries in their spring boot jar. This is often due to transitive dependencies and thus hidden from the service owner.

For example, an internal API had a V1 and V2 versions, and a service should only use one of the other. But in one case both jars were in the service jar by mistake. While it didn't break anything, it surfaced a dependency graph error coming from poor hygiene.

Something like:

springboot(
...
    check_deps_mutualexclusive = [
        # case where external maven jars are brought in, and have different artifactIds
        [ "@maven//:com_acme_anvil_api_v1", "@maven//:com_acme_anvil_api_v2" ],

        # case where workspace packages are exclusive, for example persistence layers
        [ "//projects/acme/relationaldb", "//projects/acme/graphdb", "//projects/acme/csv" ],
    ]
)

[plaird]

A major use case of this is the Boot2/Javax/Spring5 to Boot3/Jakarta/Spring6 transitions. We maintain two entire ecosystems of deps (legacy, and modern) while we transition services across. The dupe class checker actually does a pretty good job of detecting cross overs, since base libs like slf4j are different in the ecosystems.

See https://github.com/salesforce/rules_spring/blob/main/springboot/javax.md for additional features built for this use case.