Exclude `Microsoft.CodeAnalysis.Elfie` from non-Windows SDK tool layouts

### Summary
As part of dotnet/source-build#4010 ("Minimize differences between different builds of .NET"), the source-build team is working to shrink the file-level diff between the Microsoft-built SDK and the source-built SDK. One remaining real difference is `Microsoft.CodeAnalysis.Elfie.dll`, which ships in the Microsoft-built SDK under `DotnetTools/dotnet-format/` and `DotnetTools/dotnet-watch/` on **all** RIDs — including Linux/macOS, where it can never run. Source-build already strips it. This issue proposes aligning the Microsoft-built **non-Windows** SDKs with that behavior.

This was surfaced specifically by dotnet/source-build#5495.

### Why Elfie is unused on non-Windows
`Microsoft.CodeAnalysis.Features` (which ships into both tools) takes the Elfie dependency, but the symbol-search functionality it powers is unreachable outside Windows/VS:

- The Elfie-backed engine is **Windows-only at runtime in every build** — the factory returns a no-op engine on non-Windows because the backing storage relies on Windows APIs: [`SymbolSearchUpdateEngineFactory.CreateEngineInProcess`](https://github.com/dotnet/roslyn/blob/e5b5cce719cbf7479dc69814372c6e9ceb35a295/src/Features/Core/Portable/SymbolSearch/Windows/SymbolSearchUpdateEngineFactory.cs#L37-L42) → [`SymbolSearchUpdateNoOpEngine`](https://github.com/dotnet/roslyn/blob/e5b5cce719cbf7479dc69814372c6e9ceb35a295/src/Features/Core/Portable/SymbolSearch/SymbolSearchUpdateNoOpEngine.cs#L12-L32).
- The consuming feature ([`AddImport` package/reference-assembly search](https://github.com/dotnet/roslyn/blob/e5b5cce719cbf7479dc69814372c6e9ceb35a295/src/Features/Core/Portable/AddImport/SymbolReferenceFinder_PackageAssemblySearch.cs#L132-L166)) resolves `ISymbolSearchService` via MEF. Outside Visual Studio it binds to the [`DefaultSymbolSearchService`](https://github.com/dotnet/roslyn/blob/e5b5cce719cbf7479dc69814372c6e9ceb35a295/src/Workspaces/Core/Portable/SymbolSearch/ISymbolSearchService.cs#L153-L166), which returns empty results; the real implementation is the Host-layer [`VisualStudioSymbolSearchService`](https://github.com/dotnet/roslyn/blob/e5b5cce719cbf7479dc69814372c6e9ceb35a295/src/VisualStudio/Core/Def/SymbolSearch/VisualStudioSymbolSearchService.cs#L38).

So in `dotnet-format`/`dotnet-watch` the Elfie path is doubly unreachable on Linux/macOS: wrong host service layer **and** wrong OS.

### Current gating
Today the Elfie reference and its source are stripped only for source-build, keyed on `DotNetBuildSourceOnly`: [`Microsoft.CodeAnalysis.Features.csproj#L124-L141`](https://github.com/dotnet/roslyn/blob/e5b5cce719cbf7479dc69814372c6e9ceb35a295/src/Features/Core/Portable/Microsoft.CodeAnalysis.Features.csproj#L124-L141). The Microsoft build keeps it on every OS.

### Proposal
Stop shipping `Microsoft.CodeAnalysis.Elfie.dll` in the Microsoft-built **non-Windows** SDK tool layouts, matching source-build. Expected functional impact: **none** on those platforms (the code is already a no-op there).

Related: dotnet/source-build#5495, dotnet/source-build#4010

Start with src/Features/Core/Portable/Microsoft.CodeAnalysis.Features.csproj, especially the existing DotNetBuildSourceOnly gating around lines 124-141. Compare the source-build behavior described in dotnet/source-build#5495 and verify that Microsoft-built non-Windows dotnet-format and dotnet-watch layouts omit Microsoft.CodeAnalysis.Elfie.dll while Windows layouts retain it.

Written by the indexing model from the issue text.