C#: Serena's workspace/configuration handler disables decompiled-source navigation

[PoisonousJohn]

Is your feature request related to a problem? Please describe.

For C# projects, find_declaration / go-to-definition cannot resolve into assemblies that ship
without sources (NuGet packages, Unity packages such as com.unity.nuget.newtonsoft-json,
vendor SDKs). The Roslyn language server is able to do this — it bundles
ICSharpCode.Decompiler.dll and DecompilationMetadataAsSourceFileProvider, and on
textDocument/definition it decompiles the type and writes a real .cs file to
$TMPDIR/MetadataAsSource/<guid>/.../<Type>.cs.

The reason it does not happen is in Serena's own configuration handler.
CSharpLanguageServer._start_server.handle_workspace_configuration
(src/solidlsp/language_servers/csharp_language_server.py:596) answers every option whose
section name contains "navigate" with false:

if "enable" in section or "show" in section or "suppress" in section or "navigate" in section:
    # Boolean settings
    result.append(False)

csharp_navigate_to_decompiled_sources matches that rule, so Serena tells Roslyn to disable
decompilation. The generic rule looks deliberate, but the decompilation options appear to have
been caught by it accidentally: the strings decompil and navigate_to do not occur anywhere
in src/, so these sections were never considered explicitly.

Describe the solution you'd like

Exempt the decompilation/source-link navigation sections from the generic boolean rule and
answer them with true, with a comment explaining why the exemption exists (so the next reader
does not "restore" the bug on the grounds that the rule looks uniform).

Since the handler is currently a closure inside _start_server, it cannot be unit-tested; I'd
extract it to a module-level pure function first, which also allows a regression test asserting
that the other navigate options keep their current false answer.

Describe alternatives you've considered

• Leaving the handler alone and setting the option elsewhere — not possible; this handler is the
  only place that answers workspace/configuration for the C# server.
• Making the exemption a config option — the current behaviour has no benefit worth keeping
  behind a flag; disabled decompilation only removes a capability the server already has.

Additional context

Verified locally against roslyn-language-server.osx-x64.5.5.0-2.26078.4:
NavigateToDecompiledSources exists as an option in Microsoft.CodeAnalysis.Features.dll, and
with decompilation enabled Roslyn does write the decompiled .cs to disk (checked for
new List<RaycastResult>()).

Note that a second, independent guard also blocks this path today:
check_within_workspace_or_raise() (src/solidlsp/ls.py:1092) rejects the decompiled file
because $TMPDIR/MetadataAsSource/... lies outside the workspace folders. That is a separate
concern and I've filed it separately, since it belongs to the external-path abstraction rather
than to the C# server.

I'm happy to open a PR for this one — it's a small, isolated bug fix.

[opcode81]

A concept for how to handle external (non-project-relative) paths in SolidLSP is needed.