Add per-worldmap DB support and custom DB management

[kafos]

Summary

This PR adds per-worldmap SQLite database support and management improvements for NagVis worldmaps.

What is included

• Add support for worldmap_db on worldmaps (global map option).
• Keep default behavior unchanged:
  • worldmap.db remains the shared default DB.
• Support custom DBs per worldmap:
  • Custom names are normalized to worldmaps/<name>.db.
  • Missing .db suffix is appended automatically.
• Normalize values entered via “Specify other” in map options:
  • Example: geomap is stored as worldmaps/geomap.db.
• Ensure custom DB directories are created automatically.
• Fix schema initialization bug for newly created DBs:
  • use lng / lng2 (instead of long / long2) in index creation.
• Avoid inserting demo objects into custom DBs (only default worldmap.db gets demo objects).

Manage Maps UI improvements

• Add new section in Options -> Manage Maps to delete custom worldmap DB files.
• Show usage state in DB dropdown:
  • (unused) or (used by N maps).
• Prevent deletion of a DB that is still referenced by one or more maps, with a clear warning.

Motivation

By default, all worldmaps share one object store.
This makes it hard to maintain independent object sets for different worldmaps and to clean up custom DB files safely.

This PR introduces a backward-compatible way to use isolated DBs per worldmap and basic lifecycle management in the UI.

Backward compatibility

• Existing setups using only worldmap.db are unchanged.
• Existing worldmap configs keep working.
• Custom DB names entered manually are normalized to a consistent internal format.

Manual test plan

1. Create/open a worldmap.
2. In Map Options -> Worldmap, set worldmap_db to:
   • worldmap.db (default), and
   • a custom name via “Specify other”, e.g. geo2.
3. Save and verify:
   • stored value becomes worldmaps/geo2.db.
   • map objects are written/read from the custom DB.
4. Switch between maps with different worldmap_db values and verify object isolation.
5. Open Manage Maps:
   • verify custom DB list shows usage state (unused) / (used by N maps).
   • attempt to delete an in-use DB (should be blocked with message).
   • delete an unused DB (should succeed).

[LarsMichelsen]

Thank you for the PR, cool idea! 👍 I just have a few smaller remarks.

[LarsMichelsen]

I don't think the normalization should be optional (in case the function does not exist).
Same for the function_exists below.

[LarsMichelsen]

There is some duplicate logic with listCustomWorldmapDbs. Can this be unified somehow?

[kafos]

Thanks, good points.

I removed the optional function_exists() checks and cleaned up the helper handling.
I also adjusted the custom DB handling in the manage-maps view so it no longer relies on loading the worldmap source file in that context.

[LarsMichelsen]

Good improvements. What about the remaining comment regarding listCustomWorldmapDbs and list_custom_worldmap_dbs code duplication? Can you consolidate this somehow?