[FR] Extend rules database layout: support i18n and version detection

Checklist / 检查清单

• No one has submitted a similar or identical feature request before. / 之前没有人提交过类似或相同的功能请求。
• This suggestion does not depart from the original intention of LibChecker. / 这个建议不会背离 LibChecker 的初衷。

Enhancement propose / 改进目的

In my opinion two extensions for the current rules database layout would help LibChecker to get a greater audience and to support more features:

1. Introduce a column e.g. "description_en" make this database translatable. Descriptions in rules like in

https://github.com/LibChecker/LibChecker-Rules/blob/master/native-libs/libfb.so.json

are incomprehensible for most people living in countries with latin character based languages. A possibility to translate the LibChecker database to english would help a lot.

2. The LibChecker database could also store information to identify specific versions of libraries. I'm thinking of a table with following attributes:

• foreign key to rules table
• sha1 hash of the native library
• group id
• artifact id (group and artifact id may be different between different versions of the same library)
• min version
• max version (The version is a range since the native lib may be used unchanged in different versions of a library)

For most known open source libraries with native libs in the LibChecker database these information could be aggregated by scraping maven central. If those version data would be available in LibChecker database the app could identify specific versions by calculating and comparing hashes of native libs. Together with OWASP dependency check database LibChecker could even spot security issues in apps.

Another use case are decompilers: I recently used LibChecker rules database in a decompiler skylot/jadx#2040 (see sample script in issue)
Having dependency information with version numbers would make new ways possible to break code obfuscation.

The more uses cases exist for LibChecker rules database, the more people will contribute to this project.

Solution / 解决方案

No response

Additional info / 额外信息

No response

Start by reviewing the rules database example at native-libs/libfb.so.json and the requested i18n and version attributes. Research how Maven Central and the OWASP dependency check database could supply library metadata, then define the schema and acceptance criteria for both extensions.