Resolve relative BaseURLs more in line with the spec

[davemevans]

Most streams using BaseURLs that I have ever seen have sensible-looking urls which can simply be concatenated together.

Recently, I became aware of someone using an example like below (truncated for brevity):

<MPD>
   <BaseURL>http://www.example.com/manifest.mpd</BaseURL>
   <Period start="PT0S">
      <AdaptationSet>
         <SegmentTemplate media="video/v$RepresentationID$_$Number$.m4s" initialization="video/IS.mp4"/>
         <Representation id="1"/>

Whilst it looks ridiculous, according to the specification, URLs must be resolved according to RFC3986 to give e.g. http://www.example.com/video/v1_1.m4s, which is not what was happening.

This PR solves this by using the in-built browser URL parser, where available, to resolve URLs correctly with respect to a base URL. Where that URL parser is not available (IE11, Node), I have added a dumb parser which does enough to satisfy an XHR implementation for example.

I have added a number of tests, and have tested this change with as many BaseURL manifests as I could find on Chrome and Firefox (Win7), Edge and IE11 (Win10). NOTE: I have not been able to access a Mac to test this in Safari

[dsparacio]

@bbcrddave LGTM based on what I know. Ill let you merge in case you want more review.