Fixed the issue where the firstplay event wouldn't fire if the play even...

...t was fired before loadstart
> would cause the hasStarted handler to get invoked twice

The hasStarted function has a [built-in check](https://github.com/videojs/video.js/pull/1271/files#diff-3b0266ff1c037b289ec624ab25b0272eR439) to see if it's actually being changed, and only trigger events/change classes if it is. So the firstplay event will on get fired once in that scenario, and amazingly enough there was already [a test for that](https://github.com/videojs/video.js/blob/master/test/unit/player.js#L375).

I could change it to always call hasStarted(true) whenever the play event is fired. That would prevent the double hasStarted and then be almost identical to your example. I'm essentially using the "local variable" part of your previous suggestion instead of using hasClass. I'm not sure exactly why but I don't love the idea using hasClass to determine the current state.

I don't think you mean for it to fix everything but your example wouldn't work for the play-happens-first scenario when loading a new source. The loadstart event would happen after the play event and remove the has-started class, causing the big play button to keep showing while the video plays. Basically the firstplay event is dependent on both the play and loadstart events, which can happen in any order for a new source, so somewhere we have to check that both have happened before triggering firstplay.