Validate debug adapter settings before launching, beyond the TTD trace path

#910 / #1145 added validation for one specific case: the DBGENG_TTD adapter with no launch.trace_path set. That check lives in AdapterSettingsDialog::apply() and is deliberately narrow — it only covers the setting whose absence is guaranteed to fail the launch, so the dialog does not get in the way of anything an adapter would otherwise accept.

The same class of problem exists elsewhere. Settings that are required, or that point at a path which does not exist, are generally accepted by the dialog and only surface later as an adapter-specific error, if at all. Some candidates:

• common.inputFile — pointing at a file that no longer exists
• Working directory settings that name a nonexistent directory
• Remote host / port for the connect and debug-server flows: empty host, port 0, unparseable input
• Windows kernel and dump file adapters, where the target path is equally non-optional
• Executable path for the local adapters

Worth deciding on the mechanism before adding cases one at a time. Options:

1. Keep extending validateSettings() in AdapterSettingsDialog with per-adapter special cases. Simple, but the UI ends up knowing adapter-specific rules, and it does nothing for headless use.
2. Give DebugAdapterType (or the adapter) a validation entry point that returns the problems for the current settings, and have the dialog surface whatever it reports. Keeps the rules next to the adapter that owns them and can be reused by the launch path and headless callers.

Option 2 seems better long term. The #1145 change also duplicates the check in DbgEngTTDAdapter::ExecuteWithArgsInternal so scripted and dialog-skipped (#1133) launches are covered; a shared entry point would remove that duplication.

Separately, SettingsView could grow support for marking a setting as required, so the failure is visible in the settings UI itself rather than only in a message box on Accept.

Start with AdapterSettingsDialog::apply() and validateSettings(), then read the duplicated check in DbgEngTTDAdapter::ExecuteWithArgsInternal and the settings model in SettingsView. Compare the listed adapter settings and the two validation approaches; done means the chosen validation mechanism covers dialog, launch, and headless paths without leaving the current checks duplicated.