Repair the VS Code launch configurations

[tillig]

Part of #32

Proposed Changes

launch.json could not start anything. Two of its seven configurations named AspNetCore3Example and AspNetCore3ChildLifetimeScope, projects deleted some time ago, and every surviving one pointed at a bin/Debug/net6.0 or netcoreapp3.1 path for a project that targets net10.0. Meanwhile AspNetCoreChildLifetimeScope and AspNetCoreNoStartupExample are runnable and had no configuration at all. There are now seven configurations, one per launchable net10.0 project, with correct paths.

• Environment variables moved to launchSettings.json, referenced via launchSettingsProfile. All three ASP.NET Core projects already had a launchSettings.json setting the same variable, so launch.json had been carrying a duplicate copy — in the file that also had the wrong paths. One source now instead of two that can disagree.
• DOTNET_ENVIRONMENT replaces ASPNETCORE_ENVIRONMENT in those three profiles. The five .NET Framework projects keep theirs: classic ASP.NET reads neither prefix, so those entries are inert VS boilerplate and changing them would imply a behavior difference that doesn't exist.
• Removed a sourceFileMap for ${workspaceFolder}/Views. No such folder exists; the only Views directories belong to the net481 MVC projects, which aren't in launch.json.
• Removed the omnisharp.* settings. The C# extension uses the Roslyn language server now and ignores them.
• Removed the test explorer recommendation from extensions.json for a repo with no tests.
• Added dotnet.defaultSolution so the C# extension stops asking which solution to load.

Verification

I validated every configuration programmatically rather than by eye — each one names a real project, its program file exists on disk and sits under the cwd it declares, its launchSettingsProfile resolves to a profile that actually exists, and no configuration retains an inline env, a stale TFM, or a sourceFileMap. The check also runs in reverse: every launchable net10.0 project has a configuration, and no configuration names a project that doesn't exist. Seven for seven, no gaps either direction.

For the profile mechanism itself I ran AspNetCoreChildLifetimeScope through its launch profile with DOTNET_ENVIRONMENT and ASPNETCORE_ENVIRONMENT both cleared from the shell, and it reported Hosting environment: Development with both endpoints serving. So the variable really is coming from the profile. The other two profiles are structurally identical; I checked those by structure rather than launching them, since their profiles set launchBrowser: true and I didn't want to pop browsers open.

Before that I confirmed DOTNET_ENVIRONMENT is honoured by these apps at all, since the ASP.NET Core templates emit the ASPNETCORE_ form — both set the environment, so the switch is safe.

Not included

The six .NET Framework projects have no launch configuration. The five web ones need IIS Express, and WebApiExample.OwinSelfHost is a self-host exe that needs the Windows-only clr debugger rather than coreclr. I left them out rather than add configurations that fail confusingly on macOS and Linux, but say the word and I'll add a clr configuration for the self-host example.