First stab replacing url.parse with URL constructor (fixes #215)

[mozfreddyb]

Naive attempt :)

[XhmikosR]

Hehe, that's the problem :P We need a base path since we use relative URLs.

[XhmikosR]

This changes the previous behavior though. Before we defaulted to https.

[mozfreddyb]

Yeah, that's an oddity I'd like to sort out:
In https://github.com/mozilla/srihash.org/blob/master/test/helpers.js#L30-L31, we expect example.com/script.js to be completed to HTTP, but below in https://github.com/mozilla/srihash.org/blob/master/test/helpers.js#L37-L38 we autofill the protocol-relative //example.com/script.js to HTTPS.

It's not in secureHosts.json, so why do we upgrade in the latter case?

[XhmikosR]

Hmm, yeah that doesn't seem right indeed. On a side note, since the input has type="url", the user doesn't seem to be able to enter a protocol-relative file. At least with FF 66 that I use.

[XhmikosR]

This change was done in #156

So, if we trust the browsers' checks here, I think we can just drop the whole relative URLs logic (protocol-relative and schemeless).

[mozfreddyb]

We shouldn't trust the browser completely. We should try to parse with the URL constructor and return an error to the user interface if it throws

[XhmikosR]

Then why did you merge #233 :P

You can add back any stuff here after rebasing this.

BTW you should open branches upstream so that it's easier to collaborate. I will start doing it too as long as we sort #234

[mozfreddyb]

It seems I love rebasing after lunch.

[XhmikosR]

I'd change this to const missingScheme = !urlString.includes(':');

[mozfreddyb]

Not sure I understand the failures for generate(). I'll have to finish some other things today, so I'll give it another try tomorrow.