This mitigates a potential data-loss situation that might happen when
adding new music items:

  Juk starts processing the new items in addFiles,
  Results in a new CollectionListItem being created,
  The resultant PlaylistItem superclass calls setFlags,
  This causes Qt to send a *data* changed signal from the QTreeWidget
    holding all the playlist items, saying that a *different*
    QTreeWidgetItem / PlaylistItem has been changed.
  This signal is normally only possible because of user interaction with
    the inline editor. As a result JuK assumes the signal is a user
    request to edit the track's tag, and does so. I have seen this
    cause existing files to take on the same tag values as one of the
    incoming new tracks.

Although in theory a user could immediately select the "Undo" command to
fix this, that's not a very good workaround. Since we have a separate
tag editor already, we'll just use that instead until we can figure out
a way to ensure that dataChanged signals are sent only when the data
itself has changed (not just flags caused by unrelated items being
created).

CHANGELOG: Prevent opening new items from inadvertently editing track metadata on existing items.
FIXED-IN:18.12.1