Implement environment bump mapping for GeForce

[Vort]

This change allows BumpWaves test to work correctly with 45.23 driver, NV20 and NV35.
Additionally, this change fixes rendering of hardware accelerated cube from DxDiag 4.08 with 45.23 driver and NV35.

[sskras]

@Vort, welcome back – yay!

That looks like a complex piece of code. I wonder how do you reverse/manage to get all these 3D graphics details right... Looks mind-blowing to me. My warmest cheers :)

[Vort]

@sskras, thanks.
While figuring out why DxDiag 4.08 produces wrong colors with NV35, I noticed that register combiners were using uninitialized data from texture register. It happened because DxDiag 4.08 cube is not textured; however, register needed to be filled somehow anyway. For a long time I noticed cases, where both register combiners and pixel shaders were active, but didn't knew how to combine their results. Now I tried to fill texture registers with data from pixel shaders and it gave correctly colored cube.
Having pixel shaders filling texture registers made me wonder about how these registers should be filled with NV20, which has no pixel shaders. For some effects, like environment bump mapping, it is not possible to just sample single texture. Because xemu implements similar GPU, I looked for how texture registers are filled in its source code. It was possible to just implement something similar, but I wanted to have more information, so I also checked Mesa source code and found precise name of mechanism, used in such effects. Quick search revealed quite detailed document, NV_texture_shader, which confirmed formulas found in xemu code.
Unfortunately, sometimes detailed information is not available and results have to be obtained by experimentation, disassembling and guessing. For example, details about how near plane clipping works are not clear. I made several attempts at implementing it right, but each time examples appeared which showed that my guesses were wrong.