Support for relative protocol URLs when autodiscovering a feed from an HTML page.

Relative protocol URLs are of the form "//website.com/feed", without an http: or https: uri-scheme. They are intended so that a client that reads a page that includes such an URL in an element uses the same uri-scheme that was used to access the page. That is, if the page is accessed via http, the relative protocol URL is read as if it was an http URL. Conversely if the page is accessed via https, the relative protocol URL is read as if it was an https URL.

Previously this kind of URLs were not supported, the feed URLs had to have a protocol (or be relative URLs within the webpage domain) or Feedbunch would not be able to process them properly during autodiscovery. With the changes here, webpages can include relative protocol URLs in their <head> and the URL will be autodiscovered as part of the subscription or refresh.

Relative protocol URLs are not saved in the db as-is. The URL actually saved for the feed's fetch_url has an absolute protocol, matching the protocol used to access the webpage; e.g., if the user enters an http URL that leads to a page with an autodiscoverable feed URL with relative protocol, Feedbunch will save the feed with an http fetch_url. If the user enters the same URL but with an https://, the feed will be saved with an https fetch_url.

If the user enters no uri-scheme (e.g. "website.com" instead of "http://website.com"), http:// will be used by default.

Note that it is possible that this leads to a situation in which a feed is duplicated in the db, once with http and once with https. I may want to address this in the future, but it's not a priority now.