Testing mapping sets for possible breaking changes

_Note: The feature requested here may not actually belong to the ODK. Other projects, for example projects related to SSSOM, may be better suited to provide the feature. But we need to describe the feature before we can even decide _where_ it should be implemented._

We need a way to easily check whether changes to a SSSOM mapping set can break things when two or more ontologies are merged together (with the SSSOM mapping sets providing the bridging axioms between the ontologies).

Let’s say the FBbt editor makes a change to the mappings between FBbt and CL. Because FBbt has a lot of non-disjointness axioms to help ensure its internal consistency (whereas CL and Uberon do not), any such change could potentially create problems downstream when FBbt and CL are merged (for example in Ubergraph).

Currently, testing the impact of such a change requires going through complicated hoops:

* in FBbt:
* make a mock release
* in CL:
* manually import the FBbt-provided SSSOM file (overriding the default behaviour of CL’s Makefile, which attempts to always download the SSSOM file from FBbt’s GitHub repository – here, we want to test _before_ committing anything to FBbt’s repo, so before anything is available on GitHub)
* re-generate the `mappings.owl` component
* make a mock release
* In Uberon (Uberon is involved even for FBbt-to-CL mappings, because the bridge generation logic is in Uberon):
* as for CL, manually import the FBbt-provided SSSOM file
* manually import the mock CL release (again overriding the default behaviour of Uberon’s Makefile, which attempts to get CL from its GitHub repository)
* make a mock Uberon release
* generate the bridges
* Elsewhere, in a ad-hoc test directory:
* Merge the mock releases of FBbt, CL, and Uberon, along with the uberon-to-fbbt-bridge and cl-to-fbbt-bridge
* Check the resulting merged ontology for inconsistency and unsatisfiable classes.

This is ugly, needlessly complicated, error-prone, and only means that such a check will not be performed as often as it should be. As a result, mapping-generated inconsistencies will most often only be detected when someone does try to merge the involved ontologies (e.g. Ubergraph), which may very well happen months after the faulty mapping change was introduced.

We need a simple method to say, “take these two (or more) ontologies, take these mapping sets between these ontologies, merge everything together (generating the bridging axioms from the mapping sets as needed), and tell me whether the result is consistent.”