New Feature: Full host and protocol support

This is an alternative implementation of #131 which is more full featured and includes breaking changes.

### New Features:
* Adds support for specifying a default protocol in `default_url_options`.
* Adds support for specifying a default host in `default_url_options`.
* Adds support for specifying a default port in `default_url_options`.
* Adds support for routes which specify a specific protocol.
* Adds support for routes which specify a specific host.
* Adds support for routes which specify a specific port.
* Adds support for using the `window.location.protocol` when a protocol has not been specified.
* Adds support for using the `window.location.host` when a host has not been specified.
* Adds support for using the `window.location.port` when a port has not been specified.

### Changes:
* `generate_url_link` no longer validates that the `:url_links` config value contains a protocol.
* Changes expected value of `url_links` to boolean true/false and deprecates the previous usage. Default protocol, host, and port can be configured with `default_url_options`.

This PR fixes #127.
> What do you mean by "moved in context"? It is already in a context. Do you mean that the tests should be refactored so that only the tests that generate URLs based on window should set the window object?

This should be in context where we testing `window` behaviour. All another contexts should be without this defined object.

> Can you provide an example use-case which requires this support? I don't know of a situation where we would need to support that.

* Node.js
* Therubyracer
* https://github.com/railsware/js-routes/pull/121

And meny other I can find :)

 > As far as I understand, this gem is only intended to work with a Rails app.


Gem is generate JS code with Rails routes. This mean, what this generated JS code can use not only browsers and Rails app. 

Look how we works with jQuery inside js-routes. We don't depend from it and can work without it, but if jquery exists - we use it functionality.

Also, compatibility with CommonJS shouldn't be broken by another feature.