Add console versions of krita.com and kritarunner.com

For windows, build krita.com and kritarunner.com alongside krita.exe and kritarunner.exe, with the "console" subsystem instead of "windows" subsystem so they behave like a normal console application.

Using a .com file alongside the .exe is a common practice (also used by the Visual Studio IDE and Inkscape) to allow a graphical application to be run as a console application. Due to the default PATHEXT environment variable on Windows, when the user type krita from cmd in the bin dir, it prefers running krita.com over krita.exe.

Fixes: https://bugs.kde.org/show_bug.cgi?id=426948

@dkazakov I found that some code from 3rdparty\ext_qt\0003-Implement-openGL-surface-color-space-selection-in-An.patch prints debug text to stdout as opposed to stderr, which pollutes the output for example when someone may want to do krita --version. I suppose they can be removed but I figured it's better to ask you about them.

Implementation:

For krita.com: The real main entry point is split into a DLL, and a new stub main entry point is used to build both krita.exe and krita.com. The reason for doing this is to reduce the size of duplicated code and resources, since the stripped krita.exe was over 17 MB.

For kritarunner.com: The same executable is built and linked twice, since the stripped executable is smaller than 300 KB, which is not very large.

Alternative implementations that weren't chosen:

1. Setting the main EXE to "console" subsystem: This will cause a console window to appear whenever Krita is opened from outside of an existing console, which is not desirable for most users.

2. Using AttachConsole: While this can let Krita use the existing console, cmd.exe does not know to wait for Krita to finish before returning, which is different from typical console applications.

3. Using a stub .com that redirects stdio from krita.exe: This was the implementation used by Inkscape, until they found out it doesn't work nicely with readline due to not having direct access to the console. While it is unlikely to be an issue for Krita, this has another problem that, if the stub process has terminated early, there is no way for the parent process to know that Krita is still running.

Test Plan

1. Start DebugView.
2. Run krita --help or kritarunner --help from cmd -- the help output shall be printed to the console, and the prompt (C:\>) shall appear below the help output.
3. Run krita --version 2> NUL or kritarunner --version 2> NUL from cmd -- they shall print the version string with no output from QLogging, and the prompt shall appear below the version string.
4. Run krita from cmd -- QLogging output shall be printed to the console.
5. Run krita.com from Explorer -- a console window shall appear and QLogging output shall be printed to the console.
6. There shall not be any QLogging output from Krita in DebugView.
7. Run krita.exe from Explorer -- no console window shall appear, and QLogging output shall go to DebugView.

Formalities Checklist

• I confirmed this builds. (Only checked on Windows with mingw-w64)
• I confirmed Krita ran and the relevant functions work.
• [n/a] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
• I made sure my commits build individually and have good descriptions as per KDE guidelines.
• I made sure my code conforms to the standards set in the HACKING file.
• I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.