OAK generated mapping sets should be SSSOM conformant

The latest version of OAK is awesome, and thinks are looking much better. There are a number of things that should be considered for making sure OAK generated sssom files are _valid_ SSSOM. I think these should be implemented both for the `mappings` and the `lexmatch` commands.

- [ ] An empty mapping set should still have the column headers (at least the required ones, currently `subject_id`, `object_id`, `predicate_id` and `mapping_justification`. At the moment at least the mappings command does not include the columns when the result is empty, which makes it impossible to process the mapping with sssom standard conforming tools afterwards.
- [ ] https://mapping-commons.github.io/sssom/subject_source/ should be a _reference_, not a string (when validating, we get `jsonschema.exceptions.ValidationError: Slot 'object_source' has an incorrect value: UBERON`). I would suggest the following recipe for extracting a reference:
if ontology_iri (e.g. http://purl.obolibrary.org/obo/mondo.owl), take it, CURIEfy it (obo:mondo.owl). Else, assume https://w3id.org/oak/unknown_prefix/{filename}, CURIEfy it (OAK_UNKNOWN_PREFIX:{filename} (e.g. OAK_UNKNOWN_PREFIX:mondo.owl). keep `ontology_iri` general as we may use other properties in the future to get the information. Due to the "adoption" discussion its better not to use the prefix itself to determine the `subject_source`. (both mapping and mapping_set level). Dont forget to add prefixes generated this way to the curie_map.
- [ ] Mapping set id should not be _temp_ but a random IRI as per sssom-py preferences.
- [ ] There should be exactly 1 (not 2, not 0) empty lines at the end of a mapping set.
- [ ] notation should be avoided for id columns. I think we should first check if bioregistry can compress the URI, and if not, spit out a warning and not include the record.