Consider phasing out LLDB/DbgEng adapters and replace them with OS native debug adapters

Right now, the Binary Ninja debugger has been built on top of LLDB/DbgEng. They allowed a faster bootstrap of the project and allowed me to focus on the higher-level things, rather than the low-level details of debugging. However, as we move forward, I found the cost of using such high-level libraries are also mounting. The main drawbacks are:

1. They are huge and complex. LLDB requires the entire clang/LLDB to be shipped with the product, and DbgEng requires the installation of Microsoft debugging redistributable. Both are considerable in size. Sometimes the setup can be buggy and it is hard to troubleshoot and fix.
2. It is hard to set up remote debugging. Although we have this remote debugging guide (https://docs.binary.ninja/guide/remote-debugging.html), and some users do read it, they still have some difficulties setting it up correctly. Using a specialized debug adapter could make the setup easier. Also remote-debugging from macOS/Linux to Windows is not possible, since DbgEng is Windows only.
   https://github.com/Vector35/debugger/issues/70
3. They are opaque and sometimes certain bugs are very hard to fix. Although LLDB is open-source and well-maintained, its huge size makes it impractical to trace down certain bugs.
   https://github.com/Vector35/debugger/issues/304
   https://github.com/Vector35/debugger/issues/499
   https://github.com/Vector35/debugger/issues/481
   https://github.com/Vector35/debugger/issues/473
   https://github.com/Vector35/debugger/issues/433
   https://github.com/Vector35/debugger/issues/408
   https://github.com/Vector35/debugger/issues/376
   https://github.com/Vector35/debugger/issues/344
   https://github.com/Vector35/debugger/issues/137
   https://github.com/Vector35/debugger/issues/124
   https://github.com/Vector35/debugger/issues/504
4. They still have certain limitations and it is hard to expand them.
   https://github.com/Vector35/debugger/issues/497
   https://github.com/Vector35/debugger/issues/414
5. The bar of setting up the build is high. Which is not good for open-source contributors
   https://github.com/Vector35/debugger/issues/357

So I am suggesting the transition to low-level OS debugging APIs, e.g., WaitForDebugEvent on Windows. The benefits of using native OS debugging support are:

1. They are smaller and versatile
2. They are much more easier for open-source contributors to work with
3. They are not terribly hard to write. Although we probably will not be able to avoid some 3x effort to support both Windows, macOS, and Linux

Although it is unlikely we totally remove LLDB/DbgEng from the produce since they are still required fro WinDbg TTD replay/Windows kernel debugging, ios remote debugging. They are also invaluable since they provide support for LLDB/GDB/WinDbg commands, which many users like/rely on

Start by reviewing the existing LLDB/DbgEng integrations, the remote-debugging guide, and the linked debugger issues, then compare them with the proposed Windows WaitForDebugEvent approach. Done would require an agreed transition scope and acceptance criteria for native adapters across Windows, macOS, and Linux while retaining the listed LLDB/DbgEng use cases.