New Feature: Full host and protocol support

This is an alternative implementation of #131 which is more full featured.

### 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.
I'm willing to split the `window.location` code into a separate pull request if that means this pull request can be approved sooner. I still think having a `window.location` fallback is very useful. However, this doesn't solve the problem because the question still exists...what should happen if the developer does not configure a default protocol/host/port?