feat(detector/vuls2): detect OpenSSH security advisories

[MaineK00n]

Routes the openssh-security data source (MaineK00n/vuls-data-update#928) through the vuls2 CPE detection path, so a host running OpenSSH is matched against what the upstream project itself states about each release.

What

• models.OpenSSH CveContentType, and the OpenSSHExactVersionMatch / OpenSSHVendorProductMatch confidences, alongside the existing vendor sources.
• detector/vuls2/vendor.go: the source is advisory-shaped like Cisco, so it gets the same four hooks — the DistroAdvisory reference, cveContentSourceLink, toCveContentType and detectionMethod.
• detector/vuls2/vuls2.go: sourceTypes.OpenSSHSecurity joins verifiedCPESources.

Why the link is not per-advisory

OpenSSH publishes its whole security history as a single page and assigns no per-entry URL. The advisory ID (OPENSSH-<date>-<n>) is synthesised by the extractor to key the entry, so it is carried as the RefID while the link points at https://www.openssh.com/security.html.

Why it belongs in verifiedCPESources

openssh-security is the upstream project's own statement of which releases a flaw applies to, given as a bounded range per entry. It therefore dominates a supplementary source's version-less openbsd:openssh match, in the same way the Fortinet, Cisco and Palo Alto feeds do for their products. Suppression stays keyed per CVE, so it only fires where OpenSSH has an advisory for that very CVE.

Testing

go build ./... and go test ./detector/... ./models/... pass.

Independent of #2635 (Apple): the two sources touch different SourceIDs, and this branch is based on master.