lts-cve-triage.py: work directly from data/CVE/list

Following an epidemic of headaches while tackling lts-cve-triage.py-related issues at DebCamp25, we noticed that the data structure that the script manipulates is far from obvious.

It's been converted though the following different data structures:

Reference flat file (data/CVE/list)
> Python objects (lib/python/bugs.py:CVEFile)
  > Sqlite schema (data/security.db, lib/python/security_db.py) (~hourly cron for the security tracker website)
    > JSON export (security-tracker.d.o/tracker/data/json, bin/tracker_service.py, actually precomputed in lib/python/security_db.py:DB:calculateJson())
      > LTS-specific Python objects representation (bin/tracker_data.py)

(could have been worse, we didn't pass through lib/python/sectracker/parsers.py and its *.xpck cache ;))

This results in a data structure that is very, very different from the reference data/CVE/list, with confusing naming and missing data.

It would be worth re-implementing lts-cve-triage.py to work directly on data/CVE/list, through either the bugs (read-only) or the sectracker.parsers (read/write) API.

For instance, bin/syntax-check uses the former, and ELTS scripts such as bin/related-cves.py and bin/elts-trim-unimportant use the latter (not sure if one is recommended over the other).

Creating this issue as discussed with @roberto.

Limitations:

• Changes for #11 require access to both Debian and ELTS CVE lists
• data/CVE/list doesn't know about the versions published in the archive and may be wrong (e.g. ghost <no-dsa> triage for fixed versions [ex]), unless we also parse the archive versions (requires 'make update-packages' and a few GB of space)