Override incorrect dotnet paths in EtoSpecialFolders

[Miepee]

• Use XDG_DOWNLOAD_DIR on Linux for EtoSpecialFolder.Downloads (Fix GTK: EtoSpecialFolder.Downloads not following XDG user directories #2096) and the hardcoded download path for everything else.
• Use XDG_DOCUMENT_DIR on Linux for EtoSpecialFolder.Documents and the harcoded download folder for Mac
• Return XDG_CONFIG_HOME for EtoSpecialFolder.ApplicationSettings on Linux and HOME/Library/Preferences for Mac
• update some documentation

Note:
You can apparently rename core user folders in windows, and windows does update them somewhere in the registry. Thus, for EtoSpecialFolder.Downloads it would be more accurate to fetch the downloads folder from the registry.
The exact key is in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\{374DE290-123F-4565-9164-39C4925E467B}, however there's also a really neat warning with !Do not use this registry key - Use the SHGetFolderPath or SHGetKnownFolderPath function instead 🙃

[ManuelHu]

While the currently returned folders are definitely not correct, I'm not sure if this change is great for a 2.x release - it will break all applications that assume e.g. a config file has been written in EtoSpecialFolder.ApplicationSettings.

Independent of the version this will be merged into, all those applications would need some some sort of (platform dependant) upgrade code that has to replicate Eto's old behaviour to be able to migrate old settings files etc. I'm not quite sure how this should be addressed...

[Miepee]

Something that could probably help with this, is to not replace the original values.
Keep EtoSpecialFolder.ApplicationSetting, EtoSpecialFolder.Documents and EtoSpecialFolder.Downloads as they are but mark them as deprecated, and introduce something along the lines of ApplicationSettingsDirectory, DocumentsDirectory and DownloadsDirectory which return the corrected values. That way devs can slowly migrate to the fixed variants with the old methods still available.

At the end of the day, it's up to @cwensley though to decide how this should be handled.

[Miepee]

Took cwensley's suggestion in glitter/matrix and implemented a variable that determines now if the new folders should get returned or the legacy ones.
By default, it will return the new folders, but you can opt-out and use the old behaviour by setting Eto.Gtk.EtoEnvironment.UseXDG to false in your GTK application. The only affected variables by this are ApplicationSettings (Mac), Documents (Mac+Linux) and Downloads (Mac+Linux). Hope documentation for the variable is sufficient.

[ManuelHu]

Yes, that solution sounds reasonable to me. 👍🏻

[cwensley]

Thanks @Miepee for the PR! It looks great!