Fix list ordering in import/export and incomplete Select all in Tracks

[alex-dev-neo]

Two independent list bugs in the same area.

---

1. Import and export type lists come out in a different order every run

On the import selection screen (and the export screen) the data types inside a category are arranged differently each time: Tracks, Navigation history, Search history, Favourites, OSM Edits, Markers history, Map markers one run, something else the next.

+[OASettingsHelper getSettingsToOperateByCategory:addEmptyItems:] fills the per-category MutableOrderedDictionary by enumerating settingsToOperate, which is a plain NSDictionary — so insertion happens in hash order, and OASettingsCategoryItems.getTypes (allKeys of the ordered dictionary) hands that order straight to the table.

Fix: walk OAExportSettingsType.getAllValues and pick the types that are present. That is the canonical order the rest of the export/import code already uses, and it matches Android, where SettingsHelper.collectExportData iterates ExportType.availableValuesOf(category) into a LinkedHashMap.

My Places now reads:

Favourites
Tracks
OSM Edits            (plus OSM Notes when the plugin is on)
Map markers
Markers history
Search history
Navigation history

Notes:

• Fixes both screens at once — the import picker and the export picker take their data from this method.
• Category order (Settings / My Places / Resources) was never affected; those are inserted explicitly.
• "Import complete" is unaffected; it builds its rows in a hardcoded sequence already.
• All 21 types getSettingsToOperate: can produce are present in getAllValues, so nothing is dropped.
• MutableOrderedDictionary.allKeys returns [_keys array], i.e. insertion order, so fixing insertion is enough.

---

2. "Select all" in Tracks does not select everything

Selecting all in a track folder leaves tracks unselected, so deleting or sharing has to be repeated. Observed on a folder of 782 tracks: Select all covered 653 of them.

onSelectDeselectAllButtonClicked selects every subfolder, then adds the tracks of the current folder minus the ones considered to live inside a selected subfolder:

track.gpxFilePath.contains(folderName)

That is a substring test over the whole path, file name included. A root track called test1.gpx matches the folder test; anything with color in its name matches the folder color. Those tracks are silently dropped from the selection. The exclusion is not even needed in principle — TrackFolder.getTrackItems() is not recursive, so a direct child can never be inside a subfolder.

Fix: compare whole path components, and share one isTrack(_:insideSelectedFolderOf:) helper with areAllItemsSelected(), which already did the path comparison properly. The helper also requires a separator after the prefix, so folder test no longer matches a track sitting in test2.