refactor: Class-based rewrite

[alex-barstow]

Description

This is a complete rewrite using a class-based "advanced plugin" structure. This will require a new major version.

Notable changes from old plugin (not an exhaustive list)

• See api.md for full API changes
• Plugin logic is now encapsulated within 3 classes: Playlist, PlaylistItem, and AutoAdvance
• PlaylistItem objects are now a class of their own.
  • They must be constructed from objects that have a sources array of items with at least src and type properties. Sources may no longer be primitives.
• New strategy for getCurrentItem() / getCurrentIndex()
  • Whenever querying the current item or current index, the old plugin would first have to loop through all the sources in the playlist for one that matched player.currentSrc(). In addition to being confusing since the getter was acting internally as a setter, this added complexity as we had to work around cases where multiple different items could have the same source. This resulted in the playlistItemId unique id concept.
  • Now, the current index is automatically updated whenever an operation is performed that changes the order or contents of the playlist. The playlistItemId concept has been removed.
• Loading and playing behavior changes
  • setPlaylist() now only accepts a single argument and sets the internal playlist abstraction. It does not load an item.
  • Loading must be initiated afterward by calling one of the loading methods (loadItem(index), loadFirst(), etc)
  • The plugin now only calls player.play() when auto-advancing. If auto-advance is disabled, switching to a different playlist item will not play it.
• Removed duringplaylistchange event (see original reasoning for having such an event)
  • Instead of using this event to intercept the playlist setting process, integrators should do the following:

    
    // Set playlist
    playlistPlugin.setPlaylist(items);

// Perform sorting operations playlistPlugin.shuffle();

// Load first item after the playlist has been sorted playlistPlugin.loadFirst();

// Alternatively, they can use playlistchange, which happens after setting the playlist and before any item is set player.on('playlistchange', () => { playlistPlugin.shuffle(); playlistPlugin.loadFirst(); })

- `playlistchange` is now fired synchronously immediately after the playlist is updated. It is up to integrators to avoid running heavy tasks in `playlistchange` handlers.
- Methods no longer throw errors.
- Executed `@todo` changes and removed deprecated functionality
  - removed `playlistchange` event [`action`](https://github.com/videojs/videojs-playlist/blob/beba231253c9f283cd077c70770fc49384554cb9/docs/api.md#action) property. `add()` and `remove()` methods now only trigger `playlist` and `playlist` remove, not `playlistchange`
  - `playlistchange` event fires [every time](https://github.com/videojs/videojs-playlist/blob/beba231253c9f283cd077c70770fc49384554cb9/docs/api.md#backward-compatibility) a playlist is set, even the first time
- If a `remove()` call removes the current item, we now automatically load the next available `PlaylistItem`, or call `player.reset()` if none are available
- Replaced the [old poster flash solution](https://github.com/videojs/videojs-playlist/blob/beba231253c9f283cd077c70770fc49384554cb9/src/playlist-maker.js#L316-L324) with a non-index-based poster flash solution that will also handle cases when we repeat after the last item
- Various bug fixes
- Added more validation
- More robust tests
- Expanded the `index.html` demo page