Add processFilter for remote attach process selection

[afreof]

Problem

When attaching to a process on a remote target (useExtendedRemote or pipeTransport), the process to attach to always has to be picked manually from the full process list on every debug session, even though a generated launch.json already knows which executable it targets. The PID can't be hard-coded because it changes on every restart/boot, and picking the wrong entry silently produces a session with mismatched symbols and source mappings.

This mirrors the existing program-based auto-selection already used for local attach (findProcessByProgramName), which does not apply to remote attach because the remote process list comes from a different source (RemoteAttachPicker) and its label/detail shapes differ per transport.

Solution

Adds an optional processFilter (regular expression) to the cppdbg attach configuration:

• Matched against label, description, and detail of each remote process entry (the exact fields differ by transport: useExtendedRemote puts the user + full command line in label; pipeTransport puts the process name in label and the command line in detail).
• Exactly one match → attach to it directly, no picker.
• Multiple matches → show the picker, pre-filtered to only the matching entries.
• No match → fall back to the full picker, unchanged from today.
• An invalid regular expression throws a clear error instead of silently matching nothing.

Scope: this only affects remote attach (pipeTransport / useExtendedRemote). Local attach is unaffected by this PR.

Example launch.json:

{
    "name": "attach my-daemon",
    "type": "cppdbg",
    "request": "attach",
    "program": "/path/on/build/host/to/unstripped/my-daemon",
    "MIMode": "gdb",
    "miDebuggerPath": "/path/to/aarch64-poky-linux-gdb",
    "miDebuggerServerAddress": "192.168.7.2:1234",
    "useExtendedRemote": true,
    "processFilter": "/usr/bin/my-daemon"
}

Closes #14682.

Open question for maintainers

Should processFilter also apply to local attach, in addition to (or instead of) the existing program-based basename matching? Since program is a required field for cppdbg attach, both would typically be present locally at the same time, so the semantics need a decision — I'd lean towards intersecting with the program match (never letting processFilter alone select a process unrelated to program) rather than giving it precedence, but wanted to keep this PR scoped to the originally requested remote-only case and get feedback before extending it.

Testing

• Added unit tests for the matching helper (empty/non-string filter, label/description/detail matching, multiple matches, invalid regex) — see Extension/test/unit/processFilter.test.ts.
• Full existing unit test suite passes (208 passing).
• Manually verified against a real gdbserver --multi target with useExtendedRemote: true:
  • unique processFilter match attaches directly without showing the picker
  • a filter matching multiple processes shows the picker pre-filtered to those entries
  • a filter matching nothing falls back to the full, unfiltered picker (existing behavior)

[afreof]

@microsoft-github-policy-service agree company="Siemens AG"