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

[xusheng6]

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

[xusheng6]

On a second thought, I think 1) writing new adapters from the scratch can take considerable time, 2) the new adapters are not immune from these problems. So right now, I reverse course and intend to keep the existing adapters with LLDB/DbgEng, and actively work with the upstream to see if these can be fixed or addressed.