Config dir on macOS should not be ~/Library/Preferences

[Torrencem]

This is roughly a migration of the issue on the old repository. To summarize:

1. On MacOS, the library serves ~/Library/Preferences as the config directory. I consider this incorrect:
2. Apple documentation says:

You should not create files in this directory yourself. Instead, use the NSUserDefaults class or CFPreferences API to get and set preference values for your app.

3. On the apple documentation linked in the README, it seems pretty clear that config should return ~/Library/Application Support:

Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app uses to run but that should remain hidden from the user. This directory can also include data files, configuration files, templates and modified versions of resources loaded from the app bundle.

There was also some discussion of using ~/.config/ like on linux, as several popular CLI apps on Mac use this directory (neovim is mentioned, checking my .config I see neofetch as well). I don't think this is appropriate, since many more use ~/Library/Application Support (checking my mac, Firefox Inkscape llvmenv iTerm2 and Audacity are all examples which use it, usually with some kind of CLI)

So, I'm hoping that this can be resolved by changing the directory to ~Library/Application Support

[Torrencem]

Pull request is #22

[tesuji]

cc Canop/broot#103

[nmccarty]

This issue was discussed in our most recent team meeting, and we have decided that this is a bug that needs to get fixed before 2.0. We are still evaluating strategies for performing the migration, as fixing the issue would result in the undesired behavior of applications "loosing" the users config files across an upgrade, but (if possible) it will likely follow a "depreciate and swap" plan where we:

1. Create a feature gated "correct" implementation, with opt in behavior
2. Make an announcement about the new feature, and support both behaviors for the time being.
3. Issue a deprecation notice for the old, broken behavior
4. Make the new behavior the default
5. Make the "old behavior" feature redundant by always using the new behavior
6. Deprecate and remove the old feature

With appropriate time/version gaps between steps, this should give dependent crates plenty of time to warn their users about the migration.