Fix IRI "normalization"

Transport curl fails on http://example.com/#hash (fragment attached to domain directly)

## Why it fails

When requesting `http://example.com/#hash`, the actual URL requested becomes `http://example.com#hash` (no path set, the trailing slash has gone missing)

fsockopen doesn't mind, but curl dies, just as a manual curl request on `http://example.com/#hash` works fine but fails on `http://example.com#hash`, with error `Could not resolve host: example.com#hash; Host not found`

## Where it fails

URL `http://example.com/#hash` becomes `http://example.com#hash` during the following flow of events :
- `Request::request( $url, ... )` calls `Request::set_default($url, ...)`
- here, `if ($options['idn'] !== false)` invokes  `new Requests_IRI($url)`
- `Requests_IRI::scheme_normalization()` empties the path portion, as dictates the `protected $normalization` array here

## What the PR fixes

The normalization removes unwanted bits, eg `http://example.com:80/bleh` becomes `http://example.com/bleh`. Alrighty. But it goes too far.

The PR prevents the normalization to think `/` is an unneeded path 

The PR also makes sure that if we have a host but no path, the default `/` will be added.
This would probably cause problems on non http(s) requests (not sure what the requirements are for `dict:` requests, for instance) but for Requests here that's not going to be a problem.

As a result:
- `http://example.com` becomes `http://example.com/`
- `http://example.com:80#bleh` becomes `http://example.com/#bleh`
- any other kind of valid URL stays the same.

## Executive summary

![pull_request_sam](https://cloud.githubusercontent.com/assets/223647/4836462/baeb27d2-5fc4-11e4-9e4d-65ff10a1bd59.jpg)