[OntologyManager] Use in-memory SQL backend by default

[Tadinu]

Related to #141 #166 #191, this PR switches the default SQL-backend to in-memory & add general catch of sqlite3.Error from owlready2 accessing to SQL backend as a disk-file, to avoid disrupting Designator functionality.

Specifically,

• OntologyManager.create_ontology_world() -> owlready2.World.set_backend(), where sqlite3 DB access commands are invoked. Errors may happen upon a corrupt db or concurrent accesses, or a typical OperationalError would be raised amid debug process, which if sometimes prematurely ended (eg by pause/stop-debug in IDE), could result in a locked-db file on disk.
  Such errors would be treated in another PR, or even better by owlready2 itself.
  https://stackoverflow.com/a/2741015/4767815

Also, A quick resolution is deleting the SQL file on disk.
SQL backend essentially acts like a cache that is only required during program run, one if not-existing is automatically re-generated afresh from contents from the .owl, which together with all ontology data (including dynamically created concepts) can be saved anyway at program exit.

• OntologyManager: add main_ontology_sql_backend attr, allowing users to specifically set path to an SQL backend file (no need to already exist), otherwise it will be in-memory.
• OntologyManager.create_main_ontology_world(): catch sqlite3.Error
• OntologyManager.load_ontology(): in case ontology_iri is a local relative path & non-existing, make sure the file creating location is under ontology_search_path, which is settable by users
• test_ontology: only test sql_backend being saved to file in case of non-in-memory backend.

[Tadinu]

@tomsch420 @Tigul as reviewers