Feature: Support FileFolder / Folder Shortcuts / Network Locations shortcuts

### What feature or improvement do you think would benefit Files?

When creating a shortcut to a network location, Windows Explorer will create a "FileFolder". This is a read-only directory that contains a `desktop.ini` file with this content:
```ini
[.ShellClassInfo]
CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}
Flags=2
```
And it also contains a regular shortcut named `target.lnk` that points to the destination.

When the folder containing these two files is marked "Read-only", Explorer will treat it as a "fake symlink". The breadcrumbs will track the path navigated into this folder, but the actual locations of all items within are _not_ modified (which IMO is the defining difference in behaviour between these weird objects and regular ol' junctions/symlinks)

As it is right now, Files does not support these folders. Instead, it will happily navigate into the folder's "real" content, ignoring the shortcut.
While I appreciate this is a somewhat... esoteric shell feature in Windows, it is quite useful:
- Because it's a shell feature and not a filesystem feature, it works as a safe way to create "symlinks that don't have the same risk as symlinks". Delete/move/copy operations treat these folders as-is, with no special behaviour.
- Many _other_ programs that use system-provided open/save dialogs interact better with FileFolder shortcuts than bare `.lnk` shortcuts. In some scenarios, double-clicking a shortcut will give you an "invalid file" error rather than navigation. You must right-click and manually navigate instead of "Select"ing the shortcut.
- There is no "duplication" of file/folder locations when using these shortcuts. You can address filesystem items with multiple paths when using symlinks or junctions to achieve "transparent" shortcuts, whereas this feature does not allow that. Explorer will happily resolve a path and open a directory there, but if you go to view the address, you see the "real" location of the folder on disk. Files cannot be identified using paths within a FileFolder's path.

### Requirements

- When a folder is marked "read-only", check for the existence of a `desktop.ini` file directly within it. _Note: There is no constraint on the attributes of `desktop.ini`_
- If `desktop.ini` exists, read it. If it has the CLSID `0AFACED1-E828-11D1-9187-B532F1E9575D` registered under `.ShellClassInfo`, check for a shortcut named `target.lnk`.
- If this shortcut exists, and its target is both a folder and accessible, treat the containing folder as if it _were_ the target. Any `desktop.ini` file within the target folder should then be applied to this folder.
- When Files is asked to navigate to this special folder, it should also check for, parse, and handle the target as redirected.
- The folder must only be treated/parsed this way when it is being _displayed_ in an interface or as part of navigation. When any other operations discover this folder (Eg. copy, move, delete), it must be treated as a plain folder without any special behaviour.

### Files Version

2.4.49.0

### Windows Version

Windows 11 22H2 22621.1265

### Comments


Clear steps for manually creating a `FileFolder`:
1. Create an empty folder.
2. Create a shortcut to your folder destination within the folder.
3. Create a new file named `desktop.ini` and paste in the content from above.
4. Go up one level and mark the new folder as "read-only".