This commit fixes a bug that causes the music wheel to freak out when a song is placed in multiple sections.
This can occur when a user's preferred songs have a song located in two different sections.
This is only applied to Preferred Sorting because Preferred sorting is the only sort where it is possible for a song to be a part of multiple sections (e.g. A song only has 1 Title therefore it would only appear in 1 section of the SORT_TITLE).
Preferred sorting allows users to create custom groups/sections by creating a file that defines the songs and their respective sections as they should appear in the sorting. Players are now able to include a song in multiple sections. Themers are now able to display the Preferred Sort of two players on 1 screen (This previously would have caused duplicate section names to occur)
While loading all songs, disable writing the index file for the image
cache, in order to speed up loading and cache generation, similar to
how the song cache index file write is delayed.
Added delay_save_cache to SongCacheIndex so that it doesn't write the entire cache index file after every song is loaded when loading songs.
Added m_SongsByDir to SongManager so that GetSongFromDir doesn't have to walk the entire list of songs.
Minor changes to when LoadEnabledSongsFromPref occurs and how SanityCheckGroupDir works to speed up loading.
Song::ReloadFromSongDir removes cache file to force an actual reload from the song dir instead of reloading from the cache. ReloadFromSongDir exposed to lua.
Reordered Actor::LoadFromNode to put Command first because that case is more common.
Course::GetTrailUnsorted reserves entries before starting to save time reallocating.
join in RageUtil calculates the final size of the concatenated strings reserves it to save time reallocating.
Added time log file to RageLog for profiling.
The m_iSelection array could probably be made unsigned... IF we were
confident we never try to assign it a negative number, of which fact I'm
not convinced.
This is meant to be a safer alternative since
NULL can often be 0. Let's not rely on that.
And yes, I know this is a lot of files. This is
a safer thing to do in big commits vs for loops.