Link URI re: issue #486

The proposed changes address the silent failing of adding a link to an unrecognized URI. They allow the user to correct any potential mistakes made to the initial address through a prompt dialogue. 
In order to not throw a `NS_ERROR_MALFORMED_URI` with the `nsIIOService`, the string has to possess a protocol handler (from my testing, a minimum of a letter followed by a colon, ex. `h:`).  
I think prepending the http protocol handler to the beginning of a malformed string is beneficial as it recreates the assumptions the firefox address bar makes. Yes, it assumes that any added string lacking a colon is intended for a web address. However, I think that would be the most common error encountered. I'd imagine that explicitly typing http(s):// is an extremely rare occurrence for most users of modern browsers. If the link is typed (rather than copied and pasted from an address bar) I'd expect many (if not most) individuals not utilizing an alternative protocol (and therefore explicitly thinking about the protocol handler) would type www.zotero.org rather than http://www.zotero.org. However, if zotero does throw an error on strings lacking a protocol handler, I feel it would be worthwhile to suggest addressing the protocol handler to the user, as the current phrase in the error message may be a bit confusing/vague - 
>What do you mean, you don't recognize zotero.org? My firefox address bar just recognized it...

Perhaps something like 

>Zotero did not recognize the URI you entered. Please check the address and try again. (Remember to include a protocol handler, ex. https://)

Alternatively, we could just ditch the nsIIOService check in favor or a regex approach for a period within an alphanumeric string `/\w+\.\w+/`