Fixes #1018

[LloydW93]

Currently, playback resumes if you pause then seek if both autoplay and scheduleWhilePaused are true.

This is because after a see, a canplay will fire from the media element once content is in the buffer. Dash.js considers this the same as it does the first at startup and starts playback.

However, removing the startAutoPlay line from the onCanPlay event results in further problems. We use the autoplay property of the media element itself to track whether or not we are actively "trying to play", with the bonus of actually starting playback on a canplay event if that is the case.

I'm sure you'll think the direct access of element.autoplay here isn't great, and I agree and am open to ways to handle this better. I'd like to do it all in the playbackController, but part of the problem is that you can't call play() on the playbackController until it has been initialized, and it isn't initialized until the MPD is loaded etc. I'd be happy to take on board any suggestions to refactor this in a nicer way if it isn't a large piece of work.

[LloydW93]

This also resolves an issue where calling .play() when autoPlay is false has no effect.

(see https://s3-eu-west-1.amazonaws.com/smp-scratch/browserstack/jenkins-smp.browserstack.dashjs.upstream-9/Win7%20Chrome.mp4 for an example, source at https://github.com/LloydW93/dashjs-browserstack/blob/master/harness.html / https://github.com/LloydW93/dashjs-browserstack/blob/master/spec/core.js)

[dsparacio]

@LloydW93 This seems like a nice fix for the time being and maybe when we do some refactor work for the loaders and the index handlers we can include this as well.