fix: load new content when the playlist prop changes

[jwbrandon]

This PR will...

Load the new content when the playlist prop changes, instead of leaving the player on the old media. The playlist is compared structurally on each update and handed to player.load(), so the player is reused rather than remounted.

Why is this Pull Request needed?

Fixes #20 — the config was built once in the constructor, so a playlist change after mount never reached the player. Consumers had to force a remount with a key prop.

Are there any points in the code the reviewer needs to double check?

• The config is refreshed before the "no player yet" guard in shouldComponentUpdate, so a playlist that resolves while the library is still downloading reaches setup().
• A playlist that is empty or nullish is ignored, so content arriving later does not blank out a playing player.
• Only playlist is applied after setup. file/sources would need a playlist-item key allowlist to reload without dropping siblings like image and tracks, which this package deliberately avoids; the README now documents them as setup-time only.
• The reload is a side effect in shouldComponentUpdate, matching how event handlers are already handled there. componentDidUpdate would miss updates where a handler and the playlist change together.

Are there any Pull Requests open in other repos which need to be merged with this?

No.

Addresses Issue(s):

#20

[jwbrandon]

Superseded by #41, which takes the same approach — structural comparison of the playlist, handed to player.load() — but runs the load from componentDidUpdate rather than shouldComponentUpdate. React requires shouldComponentUpdate to be pure, so a render that React begins and then discards must not already have told the player to load.

The stronger parts of this PR were carried over to #41: the load() declaration on JWPlayerApi, the deepEqual unit tests, exact assertions on load's call list, the structural-equality case with nested tracks, the table over every empty playlist shape, and the README note that once<Event> handlers are subscribed at mount only.

Closing in favour of #41. Thanks for the coverage — it made the surviving PR better.