Enabling the OpenGL core profile can result in broken web video due to invalid shaders

When using an OpenGL core profile context with a Quick scenegraph, the logic in 
`QSGShaderSourceBuilder::resolveShaderPath` will return a core-profile compatible shader.  Further, the code in `qsgShaderRewriter_insertZAttributes` will correspondingly assume that the context profile should be used to determine how it modifies incoming shaders, using either core profile compatible keywords or legacy keywords ("in" vs "varying").
 
However, the assumption in `qsgShaderRewriter_insertZAttributes` isn't valid.  `QSGMaterialShader` nodes defined outside of the Quick library sometimes still return non-core profile shaders.  In particular the StreamVideoMaterialShader in stream_video_node.cpp and the YUVVideoMaterialShader in yuv_video_node.cpp don't check the profile and return legacy shaders, which become invalid when `qsgShaderRewriter_insertZAttributes` modifies them.
 
Attached is an example of the final vertex shader that was passed to the GPU when I was using a core profile my QML surface included a WebEngineView that in turn included some video content:
 
YUVVideoMaterialShader.vert.txt
 
The mixture of `varying` and `in` is not valid, nor is the use of `in` valid without a version directive.  Some GPUs and drivers will accept this, but not all (one of our downstream users is reporting this as a bug to us) and it should be corrected.  
 
A short term immediate fix would be to modify qsgShaderRewriter_insertZAttributes to do minimal parsing of the incoming shader string and verify that in core profile modes it begins with a version string.  In this case, use the core profile logic, otherwise fallback to the compatibility profile.  
 
A longer term solution would probably be to stop using simple strings to represent shaders, and instead create a structure that can store multiple strings as shader dialects, so that a tool like qsgShaderRewriter_insertZAttributes can look at the context profile and what dialects are exposed by the shader object and take the right action without fail.
 
Alternatively, all shaders could be written GLSL 430 or 450 and the build process could compile them to SPIRV.  Spirv-cross could then be used to generate, on-demand, GLSL code that was compatible with the current OpenGL context.