Feature Request: expose an `explorerResourceIsSymbolicLink` context key for when clauses

## Summary

Expose the focused Explorer item's symlink status as a when-clause context key, so extensions can contribute Explorer context-menu items that appear only when the selected file or folder is a symbolic link.

Suggested name: `explorerResourceIsSymbolicLink` (boolean), consistent with the existing `explorerResourceIsFolder`, `explorerResourceIsRoot`, and `explorerResourceReadonly` keys.

## Problem

There is no way to conditionally show an `explorer/context` menu item for symlinks. Extensions that add symlink-specific commands (for example "Go to symlink target", "Copy real path", or "Reveal original") must currently show the menu item for every file and folder, and reject non-symlinks inside the command handler with an error message.

Concretely:

1. The Explorer already tracks this state internally. `ExplorerItem.isSymbolicLink` is set when resolving the file stat, and is used by core code (for example, `fileActions.ts` skips delete confirmation for symlinks).
2. That state is never bound to a context key. `ExplorerView.setContextKeys()` binds folder, readonly, root, and editor-availability contexts, but not symlink status. The `ResourceContextKey` class likewise exposes scheme, filename, path, and language, but nothing about symlinks.
3. The documented workaround does not work for this case. The suggested pattern is to compute the state in an extension and publish it via the `setContext` command. But an extension receives no event between the user's right-click and menu evaluation, so it cannot know which tree element is about to be menu-scoped. There is no supported way to set a per-item context key in time.

The result is that every user of a symlink extension sees a context-menu entry on all files, and gets an "this is not a symbolic link" notification when they misuse it. The feature is common enough that macOS Finder ships a built-in equivalent ("Show Original").

## Requested behavior

- When the focused Explorer item is a symlink: `explorerResourceIsSymbolicLink` is `true`.
- Otherwise, it is `false` (or unset).
- The key follows the existing pattern for Explorer resource context keys: it updates when the selection or context-menu target changes, and it is usable from `package.json` menu contributions and keybinding `when` clauses.

Example contribution this would enable:

```json
"menus": {
"explorer/context": [
{
"command": "myExt.goToSymlinkSource",
"when": "explorerResourceIsSymbolicLink",
"group": "navigation"
}
]
}
```

## Implementation notes

The data already exists per Explorer item at the moment context keys are set, so this looks like a small change:

- In `ExplorerView.setContextKeys(stat)`, bind the new key alongside the existing ones (approximately one added `IContextKey` plus one `set()` call).
- Register the key in `src/vs/workbench/contrib/files/common/files.ts` next to the other `RawContextKey` declarations, so it appears in the `when-clause-contexts` documentation.
- Multi-root/remote caveats apply as they do for the other resource context keys: the value reflects the item under focus, including across multi-workspace trees and remote file system providers.
- No new API surface in `vscode.d.ts` is required, so no engine-version bump for consumers.

## Related

- #167996 — asked for a when-clause check for symlinks (closed as out-of-scope, but the suggested `setContext` workaround cannot work, as explained in the issue thread itself).
- #179307 — asked for a built-in "Reveal Symbolic Link Original" Explorer menu item; same root cause.
- #159722 — users expect symlink indication in the Explorer (the arrow decoration); the context key request is the menu/when-clause counterpart.