[3.3.x] ensure metadata update after last call to setNeedsMetadataUpdate

When metadata updates moved to the background thread this introduced a race condition where it was possible for setNeedsMetadataUpdate to be called when _needsMetadataUpdate == NO thus skipping the update while the action to update the metadata is already being executed on the background thread. With a precise interleaving this could leave the player metadata in an inconsistent state where it is still displaying the metadata from the last song even though the next song has already started playing. This wasn't possible before because the dispatch queue's sequential execution guarantee implied that the last metadata update would be after the last call to setNeedsMetadataUpdate.

This patch ensures that there will always be at least one metadata update after the last call to setNeedsMetadataUpdate. It is now possible for there to be a redundant metadata update, however if the metadata is already up to date this is idempotent thus doesn't lead to an inconsistent state. Since the metadata update isn't particularly expensive and occurs on a background thread, the cost of an extra update in some cases seems reasonable.

(cherry picked from commit 5d2b5505, backport of !840 (merged))