create fortify parser V2 - prefer true line

[paulOsinski]

• For .fpr imports, compute_line() preferred the snippet's StartLine over the vulnerability's SourceLocation line. Fortify writes snippets with 3 lines of leading context, so every finding's line (and title) was off by −3 from the line Fortify actually reports (less near the top of a file, where the snippet clamps to line 1). The true line was only preserved as SourceLocationLine: text in the description.

Since line feeds hash-code deduplication, findings imported via FPR could never dedupe against the same findings from other parsers configured on File Path + Line Number. The XML report parser is unaffected — it already uses the issue's LineStart.

Fix
compute_line() now prefers SourceLocation's line attribute and falls back to the snippet start only when it's missing.

Tests

• New regression test test_fortify_fpr_uses_true_source_location_line, confirmed failing before the fix (222 != 219), including the clamped-snippet case showing the offset isn't constant.
• Updated existing FPR test assertions that had encoded the snippet-start lines (219→222, 104→107, 5→8, 13→16, 1→3).

re: V2
many users are using the original parser, so v2 was created to avoid finding churn