Simulate the original palettized 8-bit mode using the SDL_Renderer backend

[nmlgc]

In the README, pbg highlights the split between palettized DirectDraw 8-bit and direct-color Direct3D 16-bit modes as a particularly noteworthy aspect of the period in time when this game was written:

8bit/16bitカラーの混在、MIDI再生関連、浮動小数点数演算を避ける、あたりが懐かしポイントになるかと思います。

Consequently, I've kept both modes in runnable form in every one of my releases until P0275 to preserve this historic detail.

However, SDL_Renderer doesn't provide any way to set a bit depth for the final framebuffer. And while you can specify a bit depth for each texture, the APIs and underlying hardware mostly don't support anything below 8 bits per color channel, let alone a palettized mode with color key. The software renderer does support at least two 16-bit modes, but as soon as you need transparency, there's no way around a full 8-bit alpha channel, which is only available in 32-bit formats.
As a result, the initial build that will ship #4 will only render the original 16-bit graphics and won't offer the 8-bit ones. (It will come with a separate .exe containing the old DirectDraw/Direct3D backend, though.)

But we could still simulate the 8-bit mode to at least preserve the exact original look, even if it's technically not "true" 8-bit. SDL does have support for palettized surfaces (which is the entire reason why we can load the original .BMP graphics with a sequence of 4 function calls), and SDL_Renderer can software-render onto such a palettized 8-bit surface. Thus, the basic support shouldn't involve all too much work, but who knows which tiny little issues we're going to run into for a perfect simulation – after all, it took quite a while to figure out how and why the original paletted 8-bit mode even worked to begin with.

This is about porting the 8-bit mode to modern systems. It will (probably) not make the SDL build run at full speed on period-correct Windows 9x machines, although we'd have to measure exactly how much slower SDL's software renderer would perform on such systems when compared to DirectDraw.
And yes, this simulation implies full software rendering for the entire game, followed by an upconversion from 8-bit to 32-bit for GPU-accelerated scaling every frame. Even on modern systems, it will, ironically, be much slower than the regular direct-color render path.

Depends on #63, which can be seen as a partial version of this issue that only cares about preserving the original 8-bit mode's software geometry rendering.