add suport for whatwg url policy

[createvibe]

This library is using the Legacy URL API for NodeJS. Because of this, some characters that no longer need to be encoded in the pathname are being encoded. This results in 404 or 403 responses from CloudFront when using S3 as an origin.

https://nodejs.org/api/url.html#url_legacy_url_api
The legacy urlObject (require('url').Url) is created and returned by the url.parse() function.

https://nodejs.org/api/url.html#url_percent_encoding_in_urls
Percent-Encoding in URLs#
URLs are permitted to only contain a certain range of characters. Any character falling outside of that range must be encoded. How such characters are encoded, and which characters to encode depends entirely on where the character is located within the structure of the URL.

(https://nodejs.org/api/url.html#url_legacy_api)[https://nodejs.org/api/url.html#url_legacy_api]
Legacy API#
Within the Legacy API, spaces (' ') and the following characters will be automatically escaped in the properties of URL objects:

< > " ` \r \n \t { } | \ ^ '
For example, the ASCII space character (' ') is encoded as %20. The ASCII forward slash (/) character is encoded as %3C.

In my case, an apostrophe was being encoded as %27 and causing a 403.

This PR offers a new method signature for getSignedUrl:

cf.getSignedUrl({ url, pathname, ... })

where url is the base url https://cdn.mydomain.com/ and pathname is the absolute pathname on the base url, following the NodeJS URL constructor arguments const myURL = new URL('/foo', 'https://example.org/');

This PR also exposes getWhatwgUrl, so you can call it directly:

cf.getWhatwgUrl({ url, pathname, ... })

[thmclellan]

@createvibe Thanks so much for sharing this PR, it was really useful while troubleshooting S3/CF filenames with punctuation. One minor issue I found when using getSignedWhatwgUrl() was that the policy's URL was sometimes escaped differently than the one that was generated using new url.URL, which would cause CloudFront to show an error.

I made a slight change to use the new url.URL format in the JSON policy and it fixed the issue, so the JSON policy URL and the signed URL (before the query string) were the same. (example)