Fix Go package PURL mapping by normalizing percent-encoding in plain …

[Gitjay11]

Issues

• Closes: BUG: Go package mapping fails #462

Changes

Go packages with +incompatible in their version string (e.g.
pkg:golang/github.com/docker/docker@v19.03.15+incompatible) were failing
to match against PurlDB entries. This caused the PurlDB tab to show as
disabled/empty even when "Improve Packages from PurlDB" worked correctly
for the same package.

There were two root causes:

1. Percent-encoding mismatch in PURL comparison
The old plain-PURL comparison used a naive purl_str.split("?")[0] string
split. This meant @v1.0.0+incompatible and @v1.0.0%2Bincompatible were
treated as different PURLs even though they represent the same version. The
fix introduces get_plain_purl() in dje/utils.py which normalises the
PURL through PackageURL.from_string() before comparison, so percent-encoded
and literal forms are always considered equal. plain_purls_equal() is a
thin helper that delegates to it.

2. max_request_call=1 cut off the PURL fallback on the PurlDB tab
PackageTabPurlDBView was calling get_purldb_entries(max_request_call=1),
meaning it stopped after the first lookup strategy (e.g. download_url). If
that returned nothing (common for Go packages whose inferred proxy URL isn't
indexed in PurlDB), the tab showed no results — even though a subsequent PURL
lookup would have succeeded. "Improve Packages from PurlDB" worked because it
has no max_request_call limit. The fix removes max_request_call=1 from the
view so all strategies (hash → download URL → PURL) are tried in sequence.

Checklist

• I have read the contributing guidelines
• I have linked an existing issue above
• I have added unit tests covering the new code
• I have reviewed and understood every line of this PR