`SqlImplementation` error: `no such table: prefix` if lingering `.template.db` exists in dir on instantiation

## Overview
I ran:
```
from oaklib import OntologyResource
from oaklib.implementations import SqlImplementation
sql_ontology = SqlImplementation(OntologyResource(slug='conponents/ordo.owl', local=True))
```

I got:
```
/Users/joeflack4/virtualenvs/mondo-ingest/bin/python /Applications/PyCharm.app/Contents/plugins/python/helpers/pydev/pydevd.py --multiprocess --qt-support=auto --client 127.0.0.1 --port 54993 --file /Users/joeflack4/projects/mondo-ingest/src/scripts/migrate.py --ontology-path components/ordo.owl --sssom-map-path tmp/mondo.sssom.tsv --min-id 850000 --mondo-terms-path reports/mirror_signature-mondo.tsv --onto-config-path metadata/ordo.yml --outpath slurp/ordo.tsv --use-cache --slurp-dir-path slurp/ --max-id 0999999
Connected to pydev debugger (build 222.3739.56)
robot remove -i components/ordo.owl --axioms "equivalent disjoint annotation" -o components/ordo-min.owl
relation-graph --disable-owl-nothing true \
--ontology-file components/ordo-min.owl\
--output-file components/ordo-relation-graph.tsv.ttl.tmp \
--equivalence-as-subclass true \
--output-subclasses true \
--reflexive-subclasses true && \
riot --out RDFXML components/ordo-relation-graph.tsv.ttl.tmp > components/ordo-relation-graph.tsv.owl.tmp && \
sqlite3 components/ordo-relation-graph.tsv.db.tmp -cmd ".mode csv" ".import /Users/joeflack4/virtualenvs/mondo-ingest/lib/python3.9/site-packages/semsql/builder//prefixes/prefixes.csv prefix" && \
rdftab components/ordo-relation-graph.tsv.db.tmp < components/ordo-relation-graph.tsv.owl.tmp && \
sqlite3 components/ordo-relation-graph.tsv.db.tmp -cmd '.separator "\t"' -cmd '.header on' "SELECT subject,predicate,object FROM statements " > components/ordo-relation-graph.tsv.tmp && \
mv components/ordo-relation-graph.tsv.tmp components/ordo-relation-graph.tsv && \
rm components/ordo-relation-graph.tsv.*.tmp
Sep 23, 2022 4:39:01 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
2022.09.23 16:39:01:738 zio-default-blocking-2 INFO org.renci.relationgraph.RelationGraph$
Running reasoner
2022.09.23 16:39:02:782 zio-default-blocking-2 INFO org.renci.relationgraph.RelationGraph$
Done running reasoner
2022.09.23 16:39:06:349 ZScheduler-Worker-2 INFO org.renci.relationgraph.Main.program:39
Done computing relations
cp .template.db components/ordo.db.tmp && \
rdftab components/ordo.db.tmp < components/ordo.owl && \
sqlite3 components/ordo.db.tmp -cmd '.separator "\t"' ".import components/ordo-relation-graph.tsv entailed_edge" && \
gzip -f components/ordo-relation-graph.tsv && \
cat /Users/joeflack4/virtualenvs/mondo-ingest/lib/python3.9/site-packages/semsql/builder//indexes/*.sql | sqlite3 components/ordo.db.tmp && \
mv components/ordo.db.tmp components/ordo.db
thread 'main' panicked at 'Get prefixes: SqliteFailure(Error { code: Unknown, extended_code: 1 }, Some("no such table: prefix"))', src/main.rs:45:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
make: *** [components/ordo.db] Error 101
rm components/ordo-min.owl
```

## Troubleshooting
This did not happen when I had the `.owl` file and my Python script in the same directory. In fact, I got a valid `.db` created. But when running with the `.owl` file in a subdirectory, I got this error.

## Causes
1. .template.db exists in dir on instantiation

## Suggestions
After instantiating `SqlImplementation` object, delete all remaining artefacts:
These ones (possibly) exist every time:
- `.template.db`
- `-relation-graph.tsv.gz`
These can also exist if exits early / ungracefully:
- empty `.db` (possibly)
- `.tmp.db`
- `-relation-graph.tsv`
- `-relation-graph.tsv.ttl.tmp`
- `-min.owl`

Reproduce SqlImplementation(OntologyResource(..., local=True)) with the ontology in a subdirectory, then inspect the generated commands around copying .template.db and importing the prefix table. Compare the root and subdirectory cases and verify that instantiation no longer raises “no such table: prefix” and produces a valid .db without leaving the listed artifacts.

Written by the indexing model from the issue text.