Bug 1093219 - m3u parsing

The URL constructor succeeds for "a:b" and "foo:bar", which means that it will also succeed for windows-style paths like 'c:music\song.mp3'.  I believe that catching errors is relatively slow, so I'd prefer some kind of regexp-based solution here (like looking for strings that start with http: or https:) that did not involve try/catch.