GDB Server stopOnEntry broken on embedded systems

GDB servers will always halt execution when the GDB Client attaches. MIEngine attempts to mask this through the EntryPointHit logic in HandleBreakModeEvent. #557 adds a heuristic to determine whether the break event is caused by this attach halt by checking whether the break event occurs inside a file:

https://github.com/microsoft/MIEngine/blob/2358e329427f3fd85a28fbb79bf387d13bebf8d3/src/MIDebugEngine/Engine.Impl/DebuggedProcess.cs#L1148-L1161

On embedded systems, the target will always be somewhere when the client starts the GDB server, so the "file" field is virtually always populated, even if the target is just halted at the start of its reset procedure. This breaks the "file" heuristic in the snippet above, and the entry breakpoint is deleted before it's hit.

This file based heuristic appears to be an inaccurate way to determine whether the break event is related to attach.

I'd be happy to make a PR with a fix, but I think there are multiple approaches here, and I don't really know which one would be appropriate:

1. Remove the file based heuristic altogether, and always skip break events without a reason field before the entry point when launching with a server.
2. Add a member flag that forces the debugger to skip this first break event when launching with a GDB Server instead of looking at the file field
3. Add some special handling for embedded systems, as their environment is a little different.

Related issues and PRs:

• #1108
• #1109
• https://github.com/microsoft/vscode-cpptools/issues/8011

Read src/MIDebugEngine/Engine.Impl/DebuggedProcess.cs around lines 1148-1161 and inspect the EntryPointHit and HandleBreakModeEvent logic. Compare related issues #1108 and #1109, then determine how GDB Server attach breaks should be distinguished on embedded targets. Done means the entry breakpoint is not deleted before it is hit.