Add a setting for Pathologic to output protocol-relative URLs

Oops! Here's a version of the patch that fixes the style problems. That's what I get for trying to multitask projects.

Anyway, that was an impressively quick turnaround, thank you! The only potential issue I see is in the new conversion function:

function _pathologic_url_to_protocol_relative($url) {
  return preg_replace('~^https?://~', '//', $url);
}

2 issues, one of which is probably only an academic concern (I also don't know if we should make it case-insensitive by passing the "i" pattern modifier to preg_replace(). Couldn't hurt?)

Protocols other than HTTP (an academic issue that probably doesn't matter)

This won't work with schemes other than HTTP(S), though that probably doesn't matter (I don't know if we should worry about Drupal sites running on gopher, for instance). Technically, we could support any arbitrary scheme; see RFC3986, particularly sections 3.1 (scheme definition), 3.3 (path determination), and especially 5.2.2 (algorithm for constructing target based on [relative] reference - this is the thing that makes protocol-relative URLs actually work).

The original patch tried to use Drupal's $base_url to accommodate any scheme Drupal runs on (hence all the REGEXP overkill). If we choose to support any scheme instead of just HTTP(S), it should be noted that not all schemes have a path component starting with "//" so REGEXP/strpos() searches for "//" should be converted to searching for ":" instead.

URLs that shouldn't be rewritten (this may actually be a real concern)

Not all "http://" returned by url() should be replaced with "//". hook_url_outbound_alter() lets modules modify this; the example usage changes feed URLs to point off-site. It's possible that the external server doesn't listen to HTTPS (or HTTP?) requests, so we shouldn't rewrite these URLs arbitrarily. The $base_url-derived REGEXP hooey in the original patch tried to account for this, and only changed internally-pointing absolute URLs. I think this could be an important case to handle.

I'm probably way overthinking this, and it doesn't really matter. Just a thought. Again, thanks for the awesomely fast turnaround!

For the first point, wow... talk about coincidences. I had no idea you made Drupher; that's hilarious. I agree they're all edge cases, though with the REGEXP work already in place (see below) it's free to support. I don't care; I just work in higher ed. so purely academic problems are the norm :)

For the second issue, I think that's where we still need to do some kind of comparison against $base_url; it lets Drupal determine "this is where I think I am running from" and we are sure to only modify HTTP(S) references back to the Drupal base. Anything pointing elsewhere would be untouched.

I've just merged the $base_url-derived REGEXP from the original patch with the new function in beta5. It's not pretty, but it works: anything starting with $base_url is replaced with a protocol-relative version of $base_url. I did modify the REGEXP to only support HTTP(S) as well, though we can easily revert that if desired.