cache key collision because of username URL decode in url_CryptoHash_get_general

The code in `url_CryptoHash_get_general` at URL.cc decodes percent encoding in all components of the URL, including username / password. This behaviour is incorrect and can lead to security consequences.

Consider the following scenario:

1. An ATS instance serves two domains: `attacker.com` and `victim.com`. This can happen either in forward-proxy mode or in the reverse proxy mode in some cases.
2. An attacker controls the content of `attacker.com` (e.g. can serve whatever she wants to ATS when ATS makes requests to attacker.com, as well as to instruct ATS to cache this content).
3. The attacker wants to put her content into the context of `victim.com` to achieve e.g. XSS.

The attacker can visit `http://%3A%40victim.com%2F@attacker.com/` via ATS (note the encoded characters in the username). She can do so by sending the link in the HTTP request, like this:

```
GET http://%3A%40victim.com%2F@attacker.com/ HTTP/1.1
...
```

ATS will forward this request to `attacker.com`, but the key in the cache (calculated in url_CryptoHash_get_general before hashing) will be `http://:@victim.com/:@attacker.com/`. Now, if someone visits `http://victim.com/:@attacker.com/` via ATS, it will lookup the response in the cache and serve the attacker's page, thus achieving XSS impact (the attacker can send this link to someone and execute javascript in the context of `victim.com`).

The same impact can be achieved using MD5 collisions. The cache key is hashed using MD5, and there're public tools to create an MD5 collision (including chosen-prefix ones).