Fix: if final URL contains hash, no page contents will be returned.

When the final URL contains a hash (which is not part of the URL that is sent to the server) it will be different from the one that the resource has, for example:

Resource URL: `http://m.youtube.com/index?&desktop_uri=/`
Main frame URL: `http://m.youtube.com/index?&desktop_uri=/#/home`
(you can reproduce this by opening http://youtube.com/ with iPhone's user agent)

This results in `open` not returning page data. 

The way I fix it is by stripping everything after the `#` in the frame url, before comparing it with the resource URL.

Another similar bug that might happen is if our WebKit version supports [pushState](http://badassjs.com/post/840846392/location-hash-is-dead-long-live-html5-pushstate). If it does, the main_frame url might end up being completely different than the one the resource has. In this case, we might want to switch to using the `main_frame.toHtml()` method, but it has the downside of loosing the headers and HTTP status code information. 

Therefore for now I'm just submitting solution for the hash issue.

(the Travis build fails, but only because of the unsupported_content test)