lp:~stellarium/stellarium/gz_insufficient-shader-level

This branch was intended to add more diagnostics during startup, and provides many more clearer warnings when a computer will show problems due to insufficient hardware or drivers. This should prevent many bug reports and questions concerning strange graphics problems etc.

Although Qt5 runs with OpenGL2.1, and Stellarium 0.13+ only has GLSL1.10 shaders (not 1.30 as I had assumed), in case of the ANGLE version required hardware that provides ps_3_0, which is almost equal to saying OpenGL3.0 cards.

I try to parse detected GLSL version (not sure about answers by GLES systems!), and if too low, I show a critical-error panel and more explanations in the logfile. If the user really wants, he can still continue. Currently the test is for GLSL1.30, but this should give some room.

A config flag "main/ignore_opengl_warning" has been added to suppress the panel in further runs: Some Intel systems work almost ok, just slightly degraded (e.g. only a bug in nightmode) because of unresolved glProgramParameteri().

If we ever plan to support older hardware with minimal shaders requiring only GLSL1.20/ps_2, the same startup test would be required to know which shader to compile. If not, the principal test should be changed for testing immediately for OpenGL3.0 support. For now, I left this test at 2.1 or GL ES2.0.

 I built in a few #ifdefs to have OpenGL functions which are not available in OpenGL ES still available. Code compiles with and without ANGLE, and the OpenGL version has antialiased lines.

Qt5.4 has been announced to set QGL... classes deprecated, and make ANGLE a compile-time (or even runtime? It is not available in 5.4beta) decision. Our QGLWidget will have to be changed to use QOpenGL... classes.
As Fabien has suggested, I tried to go further to replace the QGL classes (widgets, windows) by QOpenGL classes in StelMainView. This was never my intention with this branch and I feared it is beyond my understanding. I still tried a bit, but am stuck. All critical parts of this attempt are activated with a single #ifdef and compile, but not run yet, on Qt5.4beta. Someone more knowledgeable than myself please continue to finish migration of StelMainView towards Qt5.4, it is just a matter of initialisation. In the meantime, merging this with trunk would have the benefit of half a dozen hardware and driver tests with as user-friendly as possible messages available in all experimental builds.