Hard coded CURIES in OAK code cause confusion when ontologies use different prefix maps

Having pieces of code like https://github.com/INCATools/ontology-access-kit/blob/d139e99fe7faa109e0b71840e20140852a8267d9/src/oaklib/utilities/lexical/lexical_indexer.py#L52, and I think just searching there are a number of cases in OAK where these are occur, seems dangerous to me. @joeflack4 just uncovered a case where we passed in a oboInOwl prefix to semsql, which resulted in lexmatch no longer being able to understand that `oboInOwl:hasExactSynonym` (which was used in the ontology) is, in fact, the same as `oio:hasExactSynonym`. There are various ways to solve this problem:

1. No code exists where curies are defined that cant be overwritten by the user. In the ex
2. A standardised "oak context" exists to which all incoming information is standardised before processing, or, the other way around, OAK entities in the code are standardized (using curies.Converter.standardize()) against an incoming prefix map.
3. We could require that incoming semsql ontologies _must_ be standardised against the OAK context (prefix map).

None of this is particularly easy - (3) is probably easiest, but we would have to give some tool support, like

`runoak normalise-prefixes -i ont.db`.

Start with src/oaklib/utilities/lexical/lexical_indexer.py around line 52 and search the OAK code for other hard-coded CURIEs. Trace how prefix maps enter semsql and review the proposed runoak normalise-prefixes entry point; done requires an agreed approach for handling differing ontology prefix maps and supporting the affected workflow.

Written by the indexing model from the issue text.