Speedup for opening music song library

Previously, this repeatedly parsed the same URL string over and over again
for every song, each time the list of songs was opened.

Benchmarks for CMusicDatabase::GetSongsByWhere() on a Raspberry Pi with a
library of 4115 songs:

Before patch: 14.5 seconds
After patch:   4.0 seconds
Faster sorting of CFileItemLists, step 1

CFileItemLists are sorted by first construcing a SortItems object that refers
back to each CFileItem by index, sorting the SortItems object, then rebuilding
CSortItemList::m_items (a vector of pointers to CFileItems) by examination of
the sorted version of the SortItems object.

It might be more sensible, long-term, to sort m_items directly, but in the
meantime, there are a couple of simple ways to make sorting with SortItems
sufficiently efficient that it's not a problem any more.

Previously, SortItems was a vector of SortItem objects, held by value; each
SortItem was a std::map (implemented as a red-black tree) which ended up
being constructed and destructed as each element of SortItems was moved.
This patch changes SortItems to be a vector of pointers to SortItems instead.

Benchmarks for CFileItemList::Sort() on a Raspberry Pi with a library of
600 movies:
Before patch: 4.6 seconds
After patch:  1.1 seconds
Faster sorting of CFileItemLists, step 2

Each time a CFileItemList is sorted, multiple SortItem objects are
constructed and destructed. Each object is a std::map ,implemented as a
red-black tree with one node for each attribute (Field) upon which the
CFileItemList could conceivably have been sorted, even though for any given
SortBy, very few attributes are actually examined by SortUtils::Sort(). Worse
still, many of those nodes involve creating an associated fresh copy of a
string, with all the associated heap thrashing that entails.

This patch changes the various ToSortable methods to limit the number of
items in each SortItem's std::map to those actually required for performing
the chosen sort.

Benchmarks for CFileItemList::Sort() on a Raspberry Pi with a library of
600 movies:
Before patch: 1.1 seconds
After patch:  0.36 seconds
[rbp/omxplayer] Only apply boost centre to multichannel audio
[rbp/omxplayer] Avoid losing volume changes when amplification is disabled
VideoRenerers: add buffering
add buffering for GLES
WinRenderer: add buffering
DXVA: activate buffering in renderer
linuxrenderer: delete all textures on reconfigure
drop frame counter in application, ask render manager instead
vaapi: adopt to buffering in renderer
add buffering - some documentation
RenderManager: only flip free buffer if player has added something
move NUM_BUFFERS up to BaseRenderer.h
OverlayRenderer: align buffers with index in renderManager
add buffering - submit absolute time to render buffers
RenderManager: some rework, squash add buffering
dvdplayer: disable buffering unil dropping is improved
RenderManager: skip very late frames in render buffer