Allow ruby to implement screen software rendering functions

[jcm93]

Marking this as draft for now, because I was a bit uncertain about whether this was the ideal way to do this, and would also still like to double check everything.

Description

Adds calls into platform and ruby for each rendering-related function in screen, and adds the usesSoftwareRendering variable to allow for the future use of a fully ruby-implemented render path.

Motivation / Context

ares currently creates completed guest frames on the CPU, including rendering certain kinds of padding, scaling, and effects, before sending them to the video backend to be post-processed, composited and displayed.

It ought to be more efficient to perform as much of this work as possible directly in the video backend. Certain effects, particularly things like color bleed, could be more efficiently parallelized there (not to mention scaling and other compositing).

ares has expressed interest in moving further with this approach, with the emulation thread essentially just outputting a video signal, with the video backend entirely responsible for assembling this signal into frames. While I think this PR does not quite directly enable this approach¹, it begins moving in that direction by allowing the GPU to perform tasks that were previously software-rendered.

The end goal of that work would be to make ares's rendering more efficient, as well as (potentially, maybe) lowering frame latency.

A side benefit of this PR is that the video backend can be informed about the state of screen to correct for things like line doubling, interlace mode changes, and other scaling effects while the software-rendering path is still used (#1508).

Footnotes

1. I have not looked at this super closely yet. It seems like this may require changes to scanline()? It might also be that with ruby having a reference to the screen instance, it can already directly index into pixels to get granular scanline data timed with e.g. host display presents. ↩