addon/info: Include add-on title in _info.cfg
addon/mg: Refactor _info.cfg reading code into a common function
addon/mg, gui2/taddon_uninstall_list: Implement reading of add-on titles from _info.cfg

This makes it so the user-facing parts of the UI display the actual
add-on titles from the add-ons server that were stored in the _info.cfg
files when installing. I had to move more code around than I wanted for
this because gui2::taddon_uninstall_list needs to handle not just add-on
ids and names, but also list item number mappings since GUI2 doesn't
allow attaching additional data to listbox items as far as I know.

It would be desirable to allow displaying the actual unedited paths or
ids for reference purposes for the user again (e.g. manual removal of
problematic add-ons) later, without disrupting the standard workflow.
addon/mg: Use ordered sets for building the add-on removal report lists
gui2/taddon_description: Ensure color consistency with Add-ons Manager

Some of the Pango colors that were in use were only somewhat similar
(orange) or entirely different (green) to the colors used in the GUI1
Add-ons Manager.

To ensure consistency, use #rrggbb colors instead of named colors.
For future reference I've added comments specifying exactly where the
colors are supposed to come from.
Drop alternate no-op implementation of the_end()
Remove --new-storyscreens command line switch

Having a hidden switch that previously turned the_end() into a no-op is
absolutely pointless.

I've had better ideas.
Remove stub.hpp and the orphaned function using it

All this was used only by the no-op the_end() implementation.
Remove orphaned references to the log facilities in intro.cpp

We no longer use any of that here, so it's a terrible waste of time.
addon/info: Read and write last-upload TS ("timestamp" WML attribute)
addon/state: Add fallback add-on sorting enum types
gui2/taddon_filter_options: Add sorting criterion/direction options

These will be used to allow the user to change the "neutral"
(fallback) add-on sorting method used in the add-ons list when no
column header has been selected for sorting.
addon/info: Add artificial upload/creation order index field

This will be used for sorting add-ons by creation/first-upload time
in the add-ons list, since it is currently a map indexing add-ons
by name for performance reasons and otherwise the first-upload order
(determined by the add-ons list WML order as delivered by campaignd)
is completely gone since 1.10.x.
addon/mg: Implement fallback sorting algorithm/direction selection

This replaces the container-driven add-ons list sorting with
std::stable_sort() on a vector for the sake of simplicity, since now
sorting is controlled by user preferences rather than being completely
hard-coded. Alphanumerical sorting by add-on title continues to be the
default option, but now it is also possible to choose between last
upload time sorting (timestamp field in campaignd data) and first
upload order (which is the campaignd WML order, which is artificially
restored using an internal sorting index for now since the std::map
add-ons list optimization causes the campaignd order to be lost in the
pipeline). It is also possible to choose the sorting direction
(ascending or descending).

The full rationale for the whole design follows (also provided in
Doxygen comment form):

"The internal add-ons list is actually implemented employing an
associative container to map individual list entries to add-on ids for
faster look-ups. The visible form of the list may actually include more
elements than just the contents of the add-ons server; more
specifically, it may include Publish and Delete entries for local
add-ons with .pbl files.

The GUI1 list/menu class does not support horizontal scrolling, which
results in a very limited set of information columns that can be
displayed safely without running out of space and causing content to be
omitted, and clicking on any column header to change the sort also
affects the Publish/Delete entries by necessity. These two factors
combined make it inconvenient at this time to just use the GUI1
widget's interface to make it default to a specific sorting criterion.

Thus, we need a 'neutral' or 'fallback' sorting step before feeding the
add-ons list's data to the widget and appending Publish/Delete options
to it. Since this is definitely not the most evident UI concept in use
in this dialog, it is hidden behind the Options dialog and has sensible
defaults intended to optimize the add-ons experience; alphanumerical
sorting feels natural and breaks any illusion of quality rating or any
such that could result from a list default-sorted by first-upload order
as done in all versions prior to 1.11.0."

***

To recapitulate, this is probably the ugliest thing I've ever done, but
those are the limitations imposed by Wesnoth's chronic UI framework
deficiencies.
gui2/taddon_filter_option: Various UI layout improvements

 * Use "Options" as a dialog title instead of "Filter Options" for
   simplicity and to represent its current functionality better.
 * Limited dialog width to 800 pixels for readability.
 * Replaced neutral sorting options header with something that hopefully
   describes their purpose in a more user-accessible fashion.
 * The installation status options listbox now grows along with its
   containing grid.
 * Ascending/Descending options are placed closer to the sorting
   criterion selection.
 * Description labels use text wrapping when needed.
Updated the British English translation.
Simplified Rotsprite algorithm.

It is used to perform any kind of rotation with the RS imagepath
function which could only rotate in multiplies of 90 degrees previously.
Documentation and cleanups to the RotSprite methods.
Filtering for variation_type=.
Support for variation= in [unit_type].