core: allow LCD rendering to happen in separate thread

[deltabeard]

Peanut-GB would signal to the frontend that it should call gb_lcd_render_line() with copied sprite data and LCD registers.
This would allow the LCD drawing -- which requires a lot of time -- to be completed on a separate thread whilst emulation continues.

[deltabeard]

Considering this screenshot from the pandoc:

The gb_lcd_render_line() function could run in a separate thread whilst remaining within the timing of the GB CPU such that OAM is processed during OAM scan where the OAM is inaccessible (unless using OAM DMA, which is ignored here), and then the LCD rendering can be done in Mode 3, where the VRAM is also inaccessible. This means that copying the OAM and VRAM will not be necessary to render the LCD in a separate thread.

[deltabeard]

Instead or as an addition option, I think that the LCD emulation should be allowed to be performed in a separate thread or handled using co-routines, where the emitting of a pixel is timed with the CPU emulation. This will allow for the emulation accuracy of LCD to be improved by emitting the pixels at the correct time rather than only at the end of Mode 3. This also means that the VRAM, OAM, etc. do not need to be copied to perform the LCD drawing.

The same could probably be done for audio.