Refactor DirectX specific code into its own class, like OpenGL

[callsop]

• moves majority of the specific code into respective display class
• makes it possible for both opengl and directx
• defaults to trying opengl, otherwise falls back to directx
• USE_DIRECTX & USE_OPENGL can still eliminate either one, e.g. legacy, linux
• can be added to config later to allow user to choose the display driver to use

[ejaquay]

Two comments

1. Refactoring is usually a good thing but best kept seperate from commits that change or correct function.
2. I am not sure I understand all the effects of this change. Would Vcc automatically switch to directx if opengl is not available? What will happen when we start using directx (or opengl) for things other than video like enumerating and configuring game controllers or audio devices? Can one be used for game controllers while the other is rendering video?

[callsop]

1. Sure, this commit doesn't change or correct existing functionality. It merely seeks to compartmentalize directx (graphics part) that was embedded within the main emulation code, out into its own file/class. As mentioned the compile time options still functions as expected, opengl isn't included in legacy, and in future directx may not be included in a linux build if/when we get there.

2. It is setup to try initialize opengl (see boolean UseOpenGL) and failing that, initialize directx. As they are independent classes here, that makes this possible whereas before it wasn't because the directx code was mixed/baked in with a compile flag. However, if you want to keep it 'completely as before', then simply 'enable' either USE_OPENGL or USE_DIRECTX in BuildConfig.h as we did before instead of both. However, having both could be a benefit if user doesn't have opengl, it would fallback to directx, e.g. window 7?

As for other things like game controllers or audio - well, we are already doing that, no changes were ever made to audio or input when opengl was added, but I think those systems should also have 'platform' abstractions, including UI, i.e. all windows specific code, so that the emulation code isn't concerned with OS code and that they can be substituted for a future linux build.

To save any doubt, do the release you were planning anyway and leave this for next release.