fix: use url.URL to encode and decode PURLs

[tommyknows]

This commit refactors the ToString and FromString functions / methods to use the url.URL type, instead of trying to parse URLs directly.

The PURL Spec explicitly says:

A purl is a URL:
A purl is a valid URL and URI that conforms to the URL definitions or
specifications ...

So why not actually use Go's URL type to do operations on it?

This commit does exactly that, and removes a lot of the previously dense parsing-logic with simpler checks based on the URL's fields. Especially ToString() has gotten a lot simpler through that.

Additionaly, by switching to the URL package, this commit fixes a couple of outstanding bugs:

• When a qualifier contained + signs, which are valid in URL paths, but not in URL queries, the sign did not get escaped. The previous code relied on url.PathUnescape to unescape keys and values, which should have used url.QueryUnescape instead. Further, encoding Qualifiers used url.PathEscape instead of url.QueryEscape. This could have led to pURLs losing + signs if they were properly encoded.
• Fixes purl with name contain whitespace can not be built from purl string #51, where spaces in names have not gotten encoded correctly.
• Fixes most test-cases from Fix inconsistent URL encoding #22 / Inconsistent URL encoding #23 that are round-trip-save (e.g. all cases where input == output), except the "pre-encoded qualifier value is unchanged" testcase that is wrong - a qualifier shouldn't be encoded with %20 for a space, but with a plus-sign (query encoding).
• Fixes most cases from Cumulative fixes from anchore/packageurl-go #41 as well, except:
  • where the query encoding in the test-cases are wrong (" " -> "+", "+" -> "%20") (test-cases pre-encoded_qualifier_value_is_unchanged and unencoded_qualifier_value_is_encoded),
  • characters_are_unencoded_where_allowed: < should be encoded, as far as I can tell. The Go stdlib also encodes it, so this should be fine.
  • explicit_characters_are_encoded: @ does not need to be encoded.

When reading through that list and all the nuances, it makes it clear that we shouldn't do this ourselves! And this commit doesn't, it simply relies on the Go standard library to handle all of these cases correctly.

All of the aforementioned issues should have test-cases, presumably added to the test-suite-data.

---

You may notice that this code barely touches the tests. I'm not sure whether to add explicit test-cases to the Go implementation only, or if these should rather be added to the general test-suite. I'm happy to do either way - I've ensured that these changes work with all the tests from the issues & PRs mentioned above.

The only thing that does change to the test-suite is to use a multi-line matching for the JSON-data, so that not only {"key": "value"} qualifiers are valid, but also:

{
  "key": "value"
}

(not that it's currently needed, but when I added tests my editor automatically made multi-line strings out of these, so I needed to fix it 🙂)

[shibumi]

Hi @tommyknows 👋

First all thank you for your contribution. I totally agree with you here. If purls are considered URLs we should try using the go url package.

There are a few test cases failing, can you have a look at this?

[tommyknows]

Hi @shibumi, thanks, should be fixed! Missed to lowercase the type before giving it to the normalisation-functions :)

[shibumi]

Added a few comments, mostly nit picks

[shibumi]

Thank you for contribution @tommyknows , great work!! 💯