fix(gui): stop the wxDataViewCtrl lists losing the user's place - #860

SortList() ended in wxDataViewIndexListModel::Reset(), which says the
model was replaced. Every backend answers that by rebuilding its view,
and a rebuilt view starts at the top -- so an auto-sort while the user
was reading further down threw them back to row 0, horizontally as well.
With live sorting on a busy list that fires repeatedly.

A sort reorders rows; it does not replace them, and the count is the
same on both sides of the std::sort. Rows are addressed by index and
their values are pulled per cell as they are drawn, so a repaint is all
a reorder needs. Measured against a standalone sorted wxDataViewCtrl:
an insert or a value change holds the top row, Cleared()/Reset() drops
it to the first.

The bulk path cannot use that, though: AppendItemData() adds rows
without telling the control -- which is what makes a bulk load cheap --
so SortList()'s Reset() was doubling as the only notification that the
rows existed at all. Repainting there would draw a list the control
still believes is the length it was before, i.e. empty on a fresh
populate. So the sort splits: SortItems() orders and reindexes and tells
the control nothing, SortList() adds the repaint, and FinishBulkLoad()
keeps the Reset() it actually needs.

Affects every list on this base -- servers, shared files, clients,
downloads, file details, friends.

…ointers

Five things review turned up in the incremental-notification work.

Forming a group creates two children, not one. AddChild() synthesises a
copy of the parent as the first child -- the result received first -- and
notifies nobody, while AddToList() infers survival from the child count
and announces only the incoming result. So the batch said one child where
the model reports two. macOS hides it by re-reading the model as it
draws, which is the same thing that masked the original amule-project#796 defect; a
backend that builds its rows from the notifications shows a two-variant
group holding one row. Announced at the point of creation now, so a
freshly formed group is reported in full.

Sorting left the cursor addressed by row. SetSelectedItemData() restores
the selection by identity, but nothing round-tripped GetCurrentItem();
Reset() used to invalidate it along with the rest of the view, and a
repaint does not. On a live-sorted list it comes to rest on whatever file
moved into that row, so the next arrow key steps from the wrong place and
a shifted page key extends from the wrong anchor -- the same disagreement
between cursor and view that the macOS page keys were fixed for.

The pending batches held pointers vouched for by membership in a parent's
child list, which is not a liveness test: nothing in the tree ever
unlinks a child, so being listed survives being freed. CSearchFile
already broadcasts its own destruction, and CCommentDialogLst already
consumes it for this exact purpose -- the model now does too, and drops
the pointer when the result dies. The membership dance goes away with it.

Both batches now de-duplicate. SetDownloadStatus() notifies every child
of the parent it updated, so a single arrival into a 50-variant group
queued 51 entries and a busy idle window multiplied that; the control is
handed each row once.

And the comment above the idle flush still described one Cleared() per
idle as the policy, which is now only the fallback branch.

The previous commit blamed the selection and the cursor for the lists
still jumping on GTK, and guarded against it by reading and writing back
GetScrollPos(). Both halves were wrong. Measured against wx 3.3.3 and
GTK 3.24, with a wxDataViewCtrl scrolled to row 199 of 400:

  Refresh()                        toprow=199   (does not scroll)
  SetSelections(205,206)           toprow=199   (does not scroll)
  SetCurrentItem(205, on screen)   toprow=199   (does not scroll)
  SetCurrentItem(0, off screen)    toprow=0     (clamps onto the cursor)
  Reset(400)                       toprow=0

GetScrollPos() does not work on this control at all -- wx asserts "this
window is not scrollable" and answers 0 -- so the guard read 0, wrote 0,
and in a debug build produced an assertion per sort. It is gone.

The cause is the cursor restore added a commit ago, which is this
branch's own regression rather than anything older: with no row ever
clicked GTK's cursor sits at row 0, so restoring it after a sort clamps
the view onto row 0 and the list snaps to the top -- the exact behaviour
being fixed. It only bites when the cursor is off screen, which is also
when nobody is about to arrow from it, so the restore now happens only
while the row it lands on is within [GetTopItem(), +GetCountPerPage()).
Both accessors are implemented on all three backends; GTK answers 12 for
a 300px list, so the window is real rather than a fallback.

A cursor the user cannot see is left stale, as it was before this branch.
A cursor they can see is the one that has to point at the file they
clicked, which is what finding it in the wrong place after a live re-sort
was about.

On GTK and MSW the search list still resets on every burst of results:
incremental notifications abort the application there, so those backends
keep one Cleared() per idle, which drops the view to the top.

The rebuild itself is unavoidable; losing the reading position is not.
The idle branch already captures the selection and the expanded rows and
puts them back afterwards, so the row at the top joins them. Measured on
GTK with wx 3.3.3, a wxDataViewCtrl scrolled to row 199 of 400:

  after Cleared()                 top=0
  after EnsureVisible(saved)      top=199

Exactly back, not approximately: the minimal scroll GTK performs to bring
a row below the viewport into view puts it at the top. (A two-step
reach-past-and-return, which sounded more precise, lands on row 1 -- so
the simple call is also the correct one.)

This works here and not in the virtual lists because the items differ. A
CSearchFile pointer still names the same result after the rebuild; a
wxDataViewIndexListModel item is a row number, which names whatever has
since moved into it -- restoring one after Reset() does nothing, which
is why those lists avoid the reset instead.

Checked against the live tree before use, like the selection and
expansion beside it.