Detect and warn about unusable drivers when loading Mupen or switching to OpenGL rendering

The Mupen64Plus core uses OpenGL APIs in unmanaged code, which some Intel iGPUs aren't able to handle. This breaks a lot of functionality. I suggest adding a warning dialog to inform affected Intel users of this when they try to play N64 games. My understanding is that testing for OpenGL features is relatively easy to do, so we shouldn't naively flag all Intel drivers as broken.

Symptoms

(The below occur only when using OpenGL-based cores i.e. Mupen64Plus.)

• The textures of some or all polygons are replaced with solid black.
• Crashes and such:
  • EmuHawk displays an error dialog and then closes.
  • EmuHawk displays an error dialog and then remains open, but rom loading is cancelled.
  • EmuHawk hangs ("reporting this problem to Microsoft...") and then closes.
  • EmuHawk freezes (new frames are not drawn and inputs are not registered), and must be killed.

Workarounds

For users with only an iGPU (no dedicated graphics):
We've yet to understand what's wrong with the drivers, so there's no fix. Sorry about that.

For users with a dedicated graphics card:
This may affect you even if you have a proper GPU because EmuHawk might be using the iGPU instead—this seems to happen with NVIDIA "mobile" (laptop) GPUs. You can fix this with NVIDIA's companion app. The interface might change in the future, but at time of writing you can follow these steps.

Related issues

• #1074—Request for a command-line flag to disable all OpenGL calls by the front-end to prevent crashes.
• #1085—Crash on load. Intel Sandy Bridge iGPU, BizHawk 2.2.1. The issue contains a proposal like this one.
• #1352—Crash on load.
• #1470—Graphical issues. Intel Broadwell iGPU, BizHawk 2.3.1. Apparently caused by an update to Mupen/GLideN64 after 2.3.
• #1489—Graphical issues. Win7, BizHawk dev build pre-2.2.2 on branch cs73 (oops), GLideN64.
• #1526—Graphical issues and lag. Win10, GLideN64.
• #1575—Blackscreen and crash on close.
• #1662—Graphical issues, claimed to be a regression. Win10, GLideN64, BizHawk 2.4.
• #1896—Graphical issues (maybe).
• #2064—Graphical issues, and reported virtual floating-point inaccuracy. Two models of Intel Ivy Bridge iGPU, Win10 1909, BizHawk 2.4.2, Rice (GLideN64 would not start). An Intel Sandy Bridge iGPU was tested on Win8.1 and BizHawk 2.4.2, and did not show any problems.
• #2167—Freeze on load. Win10, BizHawk 2.3.1 and 2.4.2. Drivers from Win7 worked w/ Glide64 on the same hardware.
• #2192—Graphical issues. Intel Haswell iGPU, Win10, BizHawk 2.4.2. User also has NVIDIA "mobile" (laptop) GPU, but it wasn't used. Force-enabling dedicated graphics fixed the issue.
• #3210—Crashes. Intel Pentium CPU+iGPU, Win8.1, BizHawk 2.8. Fixed by switching to Rice plugin.

Extra data

• Emulation stuttery at 100%, though the machine can handle faster. Forcing EmuHawk to use the discrete GPU fixed it. Intel Comet Lake iGPU (i7-10750H), NVIDIA Turing GPU (GeForce GTX 1660 Ti).
• melonDS-emu/melonDS#1622—Buffer used without zeroing and never populated (solitaire effect). Intel Comet Lake iCPU (i5-10210U), NVIDIA Pascal GPU (GeForce MX230), melonDS x.y, Arch Linux.

Start by tracing EmuHawk's loading and rendering paths for Mupen64Plus and other OpenGL-based cores. Review the related issues for prior proposals and driver symptoms, then establish how OpenGL capabilities can be tested and what warning behavior should cover the reported failures.