Take geography into account for address computation

[lonvia]

Use the more complex way of computing the address from Nominatim for computing the rank 30 address. That makes sure that address parts are not blindly taken from the parent but geographic relations are taken into account. When streets go over boundaries, the addresses along that street will be corrected as necessary according to the administrative entity that contains them. See also Nominatim PR https://github.com/osm-search/Nominatim/pull/2082

Requires advanced SQL which is not supported by H2. Thus use the previous simpler query for tests instead.

Sadly, this PR is incompatible with #547. If it gets merged, then import time will again increase by around 50%. So it would be useful if others tested this a bit to figure out if it is worth the performance loss. I haven't made up my mind yet if I want to merge it or not.

See also discussion in #609.

[rocainunwired]

I pulled this branch, compiled with -DskipTests=true as the tests were failing.

Loaded the Nominatim DB with data only from Hyderbad, India.

Total no of records imported by photon: 18983 Import time with master branch: 40 secs (475 records/sec) Import time with this branch: 43 secs (442 records/sec)

The address hierarchy issue appears to be fixed with this branch on testing a few data points.