Use of `gl_PrimitiveID` in fragment shader should not always imply "Geometry" capability

[According to the SPIR-V specification](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_builtin), `gl_PrimitiveID`  is available with capabilities
> Geometry, Tessellation, RayTracingNV, RayTracingKHR, MeshShadingNV, MeshShadingEXT

[But glslang always uses "Geometry"](https://github.com/KhronosGroup/glslang/blob/7881226269b1596feb604515743f528f02041375/SPIRV/GlslangToSpv.cpp#L788-L789).

That means if you driver supports tessellation (or mesh or ray-tracing), but not geometry shaders, you always get a validation error.
```
vkCreateShaderModule(): SPIR-V Capability Geometry was declared, but one of the following requirements is required (VkPhysicalDeviceFeatures::geometryShader).
The Vulkan spec states: If pCode is a pointer to SPIR-V code, and pCode declares any of the capabilities listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.4.321.0/mac/antora/spec/latest/chapters/shaders.html#VUID-VkShaderModuleCreateInfo-pCode-08740)
```

Notably this is the case with MoltenVK, which has tessellation but not geometry shaders.

I believe glslang should instead use the "Tessellation" capability by default for fragment shaders, since it's a lot more likely that you have tessellation shaders but not geometry shaders, than of the opposite. Obviously being able to choose would be the best option.