Update port on scheme change + host parsing rules to the host setter + hash parsing rules

[o0Ignition0o]

On scheme change, we forgot to update the port if it's the new default one.

This will help the test :

        {
            "comment": "Port is set to null if it is the default for new scheme.",
            "href": "http://foo.com:443/",
            "new_value": "https",
            "expected": {
                "href": "https://foo.com/",
                "protocol": "https:",
                "port": ""
            }
        }

pass later, once we're done with the forward slash appending when there's no path... which is quite a challenge for now.

---

This change is 

[o0Ignition0o]

The second commit applies host parsing rules to the host setter. The ':' handling was missing.

This should let the following host example pass:

        {
            "comment": "Port number is unchanged if not specified",
            "href": "http://example.net:8080",
            "new_value": "example.com:",
            "expected": {
                "href": "http://example.com:8080/",
                "host": "example.com:8080",
                "hostname": "example.com",
                "port": "8080"
            }
        },

The remaining failing tests seem to mostly involve the forward slash bug.
There's one javascript remaining test I'm hoping to handle though :)

[o0Ignition0o]

The last commit edits the hash setting and getting rules to match the dom url hash specification

This allows the following setter test to pass:

        {
            "href": "javascript:alert(1)",
            "new_value": "castle",
            "expected": {
                "href": "javascript:alert(1)#castle",
                "hash": "#castle"
            }
        }

I would love to solve the forward slash bug, but I will probably not have enough time to tackle it for now :/

[o0Ignition0o]

a port setter test
seems to be inconsistent with a protocol setter test
There doesn't seem to be any consistency in WPT wrt the "/" when there is no path.
The specification seems to dismiss '/' at the end if there is no path:
" Otherwise, then for each string in url’s path, append U+002F (/) followed by the string to output."

@nox I don't really know how to reliably handle it, is there anything I am missing I should know ?

[o0Ignition0o]

Ok the culprit seems to be web-platform-tests/wpt@37a9631#diff-6ef48fcfe9e518dd93d4fe48a795d3ac

@SimonSapin I'll rollback until just before this commit, and push things progressively, working my way step by step

[o0Ignition0o]

Subset of of #537