Replace directories-next dependency with directories (#4661)

`directories-next` was created because `directories` was not maintained
at the time. However, `directories` has gotten active maintainership
since, and it has received more updates than `directories-next`.

`directories` also has more recent downloads than its `next`
counterpart, so it might make sense to switch to it, to avoid
unnecessary duplicate dependencies, where a project depends transitively
on both `directories` and `directories-next`.

The main question is whether we depend on any specific behavior from
`directories-next`.

crates/eframe/src/epi.rs

@@ -367,7 +367,7 @@ pub struct NativeOptions {
     pub persist_window: bool,
 
     /// The folder where `eframe` will store the app state. If not set, eframe will get the paths
-    /// from [directories_next].
+    /// from [directories].
     pub persistence_path: Option<std::path::PathBuf>,
 }
 

crates/eframe/src/native/file_storage.rs

@@ -10,12 +10,12 @@ use std::{
 /// [`egui::ViewportBuilder::app_id`] of [`crate::NativeOptions::viewport`]
 /// or the title argument to [`crate::run_native`].
 ///
-/// On native the path is picked using [`directories_next::ProjectDirs::data_dir`](https://docs.rs/directories-next/2.0.0/directories_next/struct.ProjectDirs.html#method.data_dir) which is:
+/// On native the path is picked using [`directories::ProjectDirs::data_dir`](https://docs.rs/directories/5.0.1/directories/struct.ProjectDirs.html#method.data_dir) which is:
 /// * Linux:   `/home/UserName/.local/share/APP_ID`
 /// * macOS:   `/Users/UserName/Library/Application Support/APP_ID`
 /// * Windows: `C:\Users\UserName\AppData\Roaming\APP_ID`
 pub fn storage_dir(app_id: &str) -> Option<PathBuf> {
-    directories_next::ProjectDirs::from("", "", app_id)
+    directories::ProjectDirs::from("", "", app_id)
         .map(|proj_dirs| proj_dirs.data_dir().to_path_buf())
 }