[FEATURE]: Versioning OWL import metadata db for upgradability

[mnamici]

Description

Design a versioning scheme for the ontology importer database, and provide an upgrade path from older versions.

Motivation

In future releases in may be the case that we change the schema in the ontology importer database. Since there is no way to restore it, and the user has no idea (and should not have) of this db existence and it's purpose, we would probably end up with bug reports related to the import process not working anymore.

Example Use Cases

The first thing that I can think of is to implement something like what is done for android or ios orm frameworks, probably a table with the latest db revision, and a set of SQL commands that perform the upgrade from one version to the next incrementally.

We could even consider introducing something like sqlalchemy if it helps, or write one with QtSql, or even ditch the orm entirely and use a different serialization format (but the upgrade problem still remains).

[mnamici]

Ok after giving it some thought I think for our purpose it is enough to implement a simple mechanism like the following:

1. We assign a natural number to each schema refinement [1,+inf) and increment it at every change. We can store the current version using sqlite3 specific user_version pragma, designed specifically for this purpose (so no extra table needed).
2. We store the version the plugin expects in a db-version property in the plugin spec;
3. We manage in the plugin SQL migration statements between each incremental version;
4. At startup time we query the user_version pragma value and for any integer between user_version and db-version, we run the corresponding migration script;
5. Finally, we store db-version into user-version.

EDIT: I forgot to mention that this should already be implemented for v3.3 as we only need to set the initial user_version value for this release, a one-liner during schema creation. For later releases we will deal with the migration infrastructure.

[mnamici]

I'm closing this as we got a first implementation of the version upgrade logic merged in #247 for v3.4.

It is currently very basic, providing only support for executing arbitrary SQL queries over the database but we can always come back to this and implement a more refined abstraction in the future if needed.