Move frequent locations to separate XML file

[ph10w]

Summary

• store frequent locations in a separate frequent_locations.xml file when XML preferences are enabled
• load legacy frequent-location data from config.xml when the new file does not exist, allowing it to migrate on the next save
• derive the new file path from the configured config.xml location, including when EXPLORERPP_CONFIG is used
• keep registry-based preference storage unchanged

Motivation

Frequent locations are machine-specific usage data rather than portable application preferences. Keeping them in config.xml makes that file less suitable for reuse on another PC.

User impact

Users can copy config.xml between machines without also copying their frequent-location history. Existing XML configurations migrate automatically without losing their current frequent locations.

Validation

• built Explorer++ in Release|x64
• built TestExplorer++ in Release|x64
• passed all 12 FrequentLocations* tests
• passed StorageTest.ConfigEnvVar and StorageTest.FrequentLocationsFilePath

[derceg]

Hi ph10w, thanks for working on this. I think the motivation here makes sense, given that locations will typically be tied to a single machine.

To merge this, Documentation\User\History.txt would need to be updated, with a note that frequent locations will be stored in a separate file when saving to the config file. Ideally, the documentation under Documentation\User\Sphinx would also be updated. The documentation is fairly out of date, but updating it when making changes like this is probably a good way of bringing it back up to date.

I'll also add some comments on the code itself.

[derceg]

The filename here definitely needs to change. The name config.xml was a bad choice and should really be changed, but new files should use a clearer naming scheme. Perhaps explorer++_frequent_locations.xml.

[derceg]

I think GetConfigFilePath should probably be refactored so that it takes a filename of a config file and returns the path. Something like GetPathForXmlStorageFile. GetConfigFilePath and GetFrequentLocationsFilePath can then both call that.

[derceg]

With the change above, GetFrequentLocationsFilePath would be a simple wrapper, so there would be no need for this test.