[Feature Request] Official SQLite support for UserDB and cross-platform consistency

[ruchid123123]

Problem Description

Currently, librime relies on LevelDB for user dictionaries. This leads to several issues:

1. Sync Conflicts: LevelDB's multi-file structure is prone to corruption on cloud drives (Dropbox, iCloud, etc.).
2. Ubuntu/Linux Integration Hurdles: Users attempting to use SQLite-based plugins (like librime-predict) or custom Lua-SQLite bindings on Ubuntu frequently encounter "failure to call SQLite" errors. These are often due to inconsistent linking, missing libsqlite3-dev dependencies in the default build scripts, or symbol conflicts when multiple plugins try to load SQLite differently.
3. Data Opacity: LevelDB makes it difficult for users to inspect or fix their own data.

Proposed Solution

Introduce a first-class SqliteDb implementation within the core librime library.

• Unified Dependency: By making SQLite an optional but officially supported backend, the build system (CMakeLists.txt) can consistently handle libsqlite3 detection and linking across Linux (Ubuntu), macOS, and Windows.
• Stable Storage: Use a single-file .db schema for better sync compatibility.
• Robustness: Solve the "call failure" issues on Ubuntu by providing a standard, tested path for SQLite integration.

Alternatives Considered

Maintaining separate SQLite logic in various plugins, which has proven to be unstable and difficult to configure on Linux systems.

[lotem]

I see confused goals: the user dictionary based on leveldb works well and SQLite isn't a better option; users of SQLite need to negotiate a linking convention to support their own databases but librime itself is not a user. It's not clear what the said "a first-class SqliteDb implementation" should do.

1. You should not open a database file on a cloud drive. I think this principle also applies to SQLite databases. Leveldb based user dictionaries need to be on the local file system. Use UserDictSync::SynchronizeAll to export user dictionaries to text based snapshot files on a cloud drive.
2. I don't think librime-predict uses a SQLite database. Resolving linking issue among plugins is a different goal. There is no need to introduce a build dependency in librime since building librime itself does not require SQLite, and you are suggesting that the plugins need SQLite as a general purpose database rather than a UserDb implementation provided by librime.
3. Generally, user dictionary data are processed by the algorithm built into librime and they should not be manually edited. User can export data to text files for inspection. librime provides text based table_db and stable_db if user wants to manually maintain a table.