[listview] restore scrolling to the top on a second G/End

[nfvelten]

Fixes #1734.

The second press logic only ever existed in the non-selectable branch of the G/NCKEY_END case:

if (this->is_selectable()) {
    this->set_selection(last_line);      // stops here
} else if (this->get_top() == last_line) {
    this->set_top(tail_bottom);
} else if (tail_bottom <= this->get_top()) {
    this->set_top(last_line);            // the "press again" step
} else {
    this->set_top(tail_bottom);
}

The block itself has not changed. What changed is around it: 7fa4e25 made cursor mode the default, cursor mode calls set_selectable(true) on the main views, and from then on every press takes the first branch and stops after moving the selection.

This gives the selectable branch the same second stage, guarded so it does nothing when the last line is already at the top.

Measured on a 200 line syslog file in an 80x24 terminal, pressing g then G then G and reading back the first visible line:

	after g	first G	second G
master, cursor mode	000	183	183
this patch, cursor mode	000	183	198
master, movement/mode top	000	183	198

So cursor mode now lands on exactly what the old path did, down to the 198 rather than 199, which comes from the view tail space.

One note on reproducing: I only saw the stuck behavior after passing -c ":config /ui/movement/mode cursor" explicitly. Without it my build behaved like top mode, so the reload delegate that flips the views to selectable did not appear to run on a plain startup here. That may be worth a separate look, but it is not what this patch touches.

get_selection() returns an optional, so the check goes through has_value rather than comparing the optional directly. Builds clean, and the only warning in listview_curses.cc is the pre-existing sign-compare at ov_sel >= count.

[nfvelten]

Sorry about the noise, I force-pushed. The first push accidentally included build artifacts from an in-tree build, since a lot of them are not covered by .gitignore. The branch is now just the one file.