Our support for the HLS spec is incomplete: it's based on which parts of the spec I
saw >1 year ago when connected to a mediamtx endpoint. For instance, we do not support
multi-index playlists yet, just single index / single playlist streams.

Another part of the spec we didn't support was BYTERANGEs - i.e. instead of each
segment being different files, they can be byte ranges in a single file. Or different
ranges in multiple files, or whatever.

I'm not sure if a mediamtx endpoint will ever use this, but it's possible and maybe
even likely if they use a memory cache instead of a disk cache. However, it is used
by most of the HLS samples I've been trying to test with, so supporting it is both
future-proofing and making it easier to test.

The amount of change is large, but boils down to these things:
- move HLS segment class to its own file.
- parser updates to handle byte ranges in segments and maps.
- cache changes to request segments that are byte ranges.
- cache changes to save ranges as separate files so they don't conflict.
- change list of files to download to directly load the cache via segments.
- several fixes to child url handling to load the samples.

Full disclosure: this _still_ doesn't totally work for samples because our
cache tries to pre-load all segments, and samples tend to list all of them -
potentially hours of video. For now I've put a TODO and some code in the parser
that only loads at most 10 segments per index. We should never hit this in
streaming, and for large samples it just means there's a temporary delay and
only ~1 minute of video before it crashes. In the future we should preload a
couple, then do the rest in the background or on demand.