Improved system_paths list generation for Windows.

[Enyium]

• Added various paths including for virtual folders. [Tested as working in Windows Explorer and Directory Opus.]
• Corrected resolving of paths like "Downloads", which the user may have changed using the Explorer properties dialog of the respective virtual or resolved folder. [Perhaps, it's also relevant for other OS languages than English?]
• Fixed bug where path adjustments made by the algorithm weren't reflected in aliases. [Because aliases were added too early.]

---

For platforms other than Windows, I left the # TODO: Correct this for Mac and Linux. Since I only use Windows, I don't know whether this needs any adjustments. But the behavior for these platforms shouldn't have changed. So, even if what directly follows the todo is incorrect, then it already was before, and fixing it wouldn't need to be done by this PR.

I also don't use OneDrive, so couldn't fix any possible problems with the code that adds OneDrive subpaths. But I kept it.

[nriley]

Thanks, this seems a useful thing to have on Windows. I made a small code comment, but three larger issues:

1. This change adds a lot of new system paths, but host-specific .talon-list files don't get regenerated to add them if they already exist, so existing users won't get any of these new paths.
2. I'm not sure we need to have so many ways to say something, e.g. 3 ways to say "virtual desktop", particularly when this adds 3 identical .talon-list entries. Please just pick one.
3. Virtual folders don't work in CMD or PowerShell. They may want to be separated out into a separate list to be Windows Explorer-only.

I think #3 may be a good solution for #1; just separate the virtual folders out into a separate list. By definition they don't need to be customized per-host like the other system paths.

[Enyium]

I'm not sure we need to have so many ways to say something, e.g. 3 ways to say "virtual desktop", particularly when this adds 3 identical .talon-list entries. Please just pick one.

Should the previously existing aliases "desk" and "docks" also be removed? I defined "virtual desk", e.g., because of the existence of "desk". If "desktop" is worthy of a shorter alias, I thought "virtual desktop" is too.

---

I don't understand the necessity of the pass-through capture user.system_path. It doesn't even change the data type. It just made the list user.system_paths be named wrong, because lists normally have singular names. (Can lists and captures really not have the same name?) Can the capture be removed and the list be renamed to the current name of the capture? (BTW, this would also resolve the conflict of competing system_paths-<hostname>.talon-list files, once in core [generated in the past] and once in core/system_paths where I grouped the files in, because they became more and more and don't all start with the same text. The new file would then be called core/system_paths/system_path-<hostname>.talon-list [singular] - same principle as in core/formatters.)

Also, theres the explanation at the top of system_paths.py: "It also creates a file system_paths-<hostname>.talon-list in the core/system_paths folder, so the user can easily add their own custom paths." If the user adds custom paths, they're not system paths. The only reason I see to not have a user.system_path list in memory only is because the user may want to change spoken forms or add aliases. Not being updated when the code in the upstream repo changes is the downside of this. But if the list doubles as a way to provide custom paths, it would actually need to be renamed, or there would need to be a third list for custom paths (along with combining captures).

---

There seems to be a problem which may be out of the scope of this PR:

file_manager.py defines this capture:

@ctx_file_manager.capture("user.address", rule="{user.system_paths}")
def address(m) -> str:
    return str(m)

If you'd change the rule to <user.possibly_virtual_system_path>, so that apps like Windows Explorer (but also other third-party GUI file managers) are affected as intended, this would influence various terminal apps, which is undesired.

file_manager.talon always activates the tag user.address. In finder.talon and windows_explorer.talon, both tags user.file_manager and user.address are activated (so, user.address unnecessarily). Can the activation of user.address in file_manager.talon just be removed or would that affect other apps incorrectly? Do terminal apps that don't explicitly specify user.address need it? Finder seems to require it. So, there seems to be inconsistency that's hard to resolve.