(cherry picked from commit 9a0181ec)

Conflicts:
	CMakeLists.txt

I introduced this bug in commit a800c1b3 trying to fix a different
memory mis-using bug. Sigh.

In this case playlists that reserve additional columns would get a valid
memory assignment but would be copied into the memory block incorrectly.
This needed a back_inserter as well.

Thanks to Markus for pointing out the regression, then opening a bug,
then leaving a comment to point out both of these, and then drafting a
patch that fixes the bug.

I can confirm it works in my testing, it also seems to address a bug
relating to playback stopping abrupting at the end of a track instead of
skipping to the next track, but who knows at this point.

BUG:420718
FIXED-IN:20.04.1

(cherry picked from commit a22c1fc8)

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

This seems to have been present in the theming data we borrowed from
Amarok. Removing the duplicate SVG element doesn’t seem to cause any
graphical issue in the scroll bar (where we use the theme).

`item` was also the parameter name of the playlist item that completed
the inline editing process.

We store pointers to other `Playlist` entries to ensure we can update
their playing item state (which in the old JuK was a 'playback arrow'
icon that would show up in the row for playing items). The idea being
that there would be an entry in the Play Queue showing that an item was
playing but also the same source item in the source playlist would also
indicate that it was playing.

This has been susceptible to all the normal frailties of storing
pointers to objects whose lifetime is unpredictable. By using guarded
pointers we can at least hopefully avoid crashing (especially on
shutdown).

This is another bug detected by LGTM
https://lgtm.com/projects/g/KDE/juk?mode=list

`loadFile()` itself calls at least four virtual methods. Rather than
trying to de-virtualize them as I did in the last fix, I decided to just
have the file load happen after the class is fully constructed, using
the Qt event loop.

The LGTM code scanning site has coverage of JuK by virtue of its Github
mirror, and reported [1] that `Playlist` was calling a function that was
indirectly reliant on a virtual function (`columnOffset()`) that is
overridden by subclasses like `HistoryPlaylist`.

This is a bug since the C++ language specifies that a superclass
constructor will be statically bound to call its own version of a
virtual function (or an even higher superclass's), rather than whatever
the subclass reimplementation might ultimately be.

This is fixed by using the data we already have at the time of
construction to set aside the right number of columns and then just
holding onto the header labels generated rather than trying to
introspect later.

[1] https://lgtm.com/projects/g/KDE/juk?mode=list

When the search filter was activated then the test for being the topmost
item would be wrong (there would be a topmost item but it's probably
filtered out!). Instead use the existing check for the *visible* item,
which wasn't even reached by the buggy code.

The search bar was broken because a missing `returnPressed` signal
declaration broke the signal/slot chain that was already present. An
update to the existing key press filter was sufficient to make pressing
return on a selected track in the Playlist work again, without the
downsides of using `QListWidget::itemActivated`.

Search playlists that are loaded with JuK on startup (i.e. because they
were saved from a previous JuK invocation) cause a crash as soon as you
click on the playlist after the recent merge request !18 (which
refactors the search-handling code).

The direct cause is that we were passing a pointer to a stack-allocated
object (in the operator>> for SearchPlaylist), which caused a dangling
pointer once the flow of execution left the stack frame. I did not catch
this during the code review, but found a second instance of this in
PlaylistCollection which I've also fixed.

Fix SearchPlaylist creation

See merge request kde/juk!19

PlaylistSearch was not set. It also cannot be constant as it is
editable, leading to a cascade of changes that assumes the constantcy.

This fixes the regression caused by commit
8dc85041

Proxify PlaylistSearch

See merge request kde/juk!18