Sortable unit overview

[SomeTroglodyte]

Draft due to open questions - help welcome

Questions

• Initial sort: SortableGrid will sort on first use if I define which column that is in the initial parameters. But if I don't, iteration order of the data source determines order. The old code did its own sort using untranslated display name, the due flag, no more movement points, and distance from map center. But civ..units.getCivUnits() already has a deterministic order - if we were to use getCivUnitsStartingAtNextDue, it would give us the exact order the Next-Thing button gives... Was no difficulty before as the sort was done only once on opening empire overview. With interactive resort, however... See also comments in source.
  • Options:
  • Include that sort definition as Sequence - lots of lost CPU each time the grid resorts
  • Materialize the result of that sort - additional memory
  • Decide on a different initial sort order
  • Teach SortableGrid how to have an invisible column, give that column the comparator, then define it as initial sort

Not this PR, but it popped up

• I noticed the city grid name column hardcodes the Settler's icon as its header icon - what if we're playing a mod that doesn't have a Settler unit?
  • Options:
  • Code a fallback to OtherIcons/Cities - tried and straightforward but a few lines of code extra
  • Shouldn't we define an individually moddable path like "OtherIcons/CityOverviewNameColumn" or somesuch and deliver a copy of the Settler icon as such?
  • Isn't it an imperfection too that OtherIcons/Cities is reused for settling suggestion overlays on the map, civilopedia and empire overview categories - maybe I'm even missing one - no individual modding?
• CityOverviewTab doesn't implement the select API - but it easily could. Worth it, so e.g. if I call city overview with a City selected on the map it would navigate to that city?

Side story

git cost me days of lost effort on this. Redo from a disk copy with Meld? thrice or so. Dump and start over? Several times - first such branch was last year. But this time I radically deleted the entire workspace and rebooted it as a fresh clone from the fork to make git forget... Something as easy as "I have missed removing a todo that the commit 4 places down already solved - let's commit that individually and squash down" led to un-abortable, un-resolvable rebases with oodles of lost source code and no trace... Necessitating spying the hash of the last good pre-squash commit from the logs, then, due to lost trust - do a checkout on that, then copying the source tree, then pushing the branch, then "rebooting" as described, then pulling the branch back, then undoing each commit individually and and converting it into a shelved entry, then delete all so far used branches, git gc --prune=now --aggressive so it forgets as much as possible again, then unshelving all those commits in the right order...