Configuration of data/config/log directories has discrepancy between OSes that causes aw-server-rust to place it's folders in the program's Parent folder on Windows

- [x] I am on the [latest](https://github.com/ActivityWatch/activitywatch/releases/latest) ActivityWatch version (v0.13.0 as of submission).
- [x] I have searched the issues of this repo and believe that this is not a duplicate.
____________________
After a discussion with Erik on Discord, the issue comes down to how the default Windows directory for ActivityWatch is `%LocalAppData%\activitywatch\activitywatch\` compared to the other platforms that simply use an overall `./activitywatch/` folder.

the aw-server-rust module uses the crate call below from `appdirs` to find the desired configuration directory:

```
appdirs::user_config_dir(Some("activitywatch"), None, false)
```
This works as expected for other platforms, but seems to be the culprit of the below resultant folder structure:
compared to the main (sub)folder:

The code for the first run legacy import uses a modified call to ensure the correct location is selected:
```
appdirs::user_data_dir(Some("activitywatch"), Some("activitywatch"), false)
```

This can probably be broken up into pieces as
- aw-server-rust should be able to find the correct folder as configured. The way the configuration is being imported by the Path matching method may benefit from improved robustness (e.g. whether or not it should just be grabbing the first matching "activitywatch" folder from the config path result).
- There doesn't really seem to be a benefit to this nested folder structure for one platform, and seems worthwhile to use a similar folder structure to the other Platforms. This would involve a migration/check for those on Windows, but could also be handled in a similar way to the legacy_import.rs function for the aw-server-rust module.
- Lastly, this did re-surface that the folder configuration (among other default settings/configuration) has multiple "config" locations for different modules (even the bundled ones), and leads to the potential for discrepancies in default configs. It seems like, for maintainability, it may be good to use an explicit parent config file that could then be "overridden" by module-specific configs as needed or by the user. This is functionally similar to the current setup, but would allow for an explicit default config file that is easier to track for development. This would also still enable community modules to supply their own configs.

-Any Windows:
- v0.13.0:

## Additional context

Any changes decided here should be coordinated with updates to the documentation about the folder configurations as needed.
https://docs.activitywatch.net/en/latest/directories.html