Feature/epsg codes with latlon ordering to runtime database

[ridoo]

This feature will add a new table to the PublicDatabase and fill it with EPSG codes which are actually defined with lat/lon axes order. Ilwis uses simplified axes order, i.e. lon/lat or x/y axes order (which could be denoted to be easting/norhting).

It is clear that other orderings do exist. However, we should not accept data sources which say either "do it according to specification", or "do it always lon/lat" as this will result in having datasets (doing it the other way) will result in wrong results.

With this pull request Ilwis will keep all EPSG codes which are defined with lat/lon order in a simple database table. A Resource can then be prepared with a forceXY property to indicate if a connected data source enforces lon/lat order or if it respects the defined axes order specification according to the EPSG database.

The WFS Connector implementation for example assumes by default that defined axes order is respected by the connected Web Feature Service. Within the OGC world the specification rules. If for some reason there is a WFS which provides lon/lat ordered coordinates only (even for lat/lon specified CRS) the WFS can be prepared by

Resource resource("http://localhost/application/wfs?service=WFS", itCATALOG);
resource.addProperty("forceXY", false);
ICatalog cat(resource);
// ...

This pull request addresses issue #58, whereas no integration to the GeometryHelper has been done so far. Anyway, integration should be easy by querying the affected EPSG codes via

static bool isDefinedAsLatLonAxesOrder(ICoordinateSystem crs)
{
    QString sqlBuilder;
    sqlBuilder.append("SELECT code FROM epsgcodeswithlatlonaxesorder ");
    sqlBuilder.append(" WHERE code='");
    sqlBuilder.append(crs->code());
    sqlBuilder.append("' ;");

    QSqlQuery query(kernel()->database());
    query.exec(sqlBuilder);
    // exact one or no match
    return query.next();
}