Fix silent elimination of fragment shaders (Issue #284)

[zmr-233]

Problem

When a fragment shader writes only its RGB components (leaving w uninitialized), dead-code elimination (DCE) would drop the entire entry point without warning. The SPIR-V still compiled, but at runtime the shader was missing entirely.

What changed

• Post-DCE check: after the second DCE pass, we now scan all declared entry points and verify their functions still exist. Added validate_entry_points_exist() function that runs after the second DCE pass.

• Error reporting: if an entry point is gone, emit a clear error.

  • Fragment shaders get a specific hint to use full-vector writes (e.g. *out = vec4(r,g,b,a)).
  • Other shaders get a generic “no observable effects” message.

• Added comprehensive test cases:

  1. issue-284-dead-fragment-good.rs - Working fragment shader with proper output assignment
  2. issue-284-dead-fragment-bad.rs - Problematic fragment shader that triggers the new validation

Effects

The fix provides context-aware error messages:

error: entry point `main_fs` was eliminated during dead code elimination, likely because its function body was optimized away
   |
   = help: fragment shaders must write to output parameters. Use complete assignment like `*out_frag_color = vec4(r, g, b, a)` instead of individual component assignments
   = note: example: `*out_frag_color = vec4(in_color.x, in_color.y, in_color.z, 1.0);`
   = note: entry point functions that produce no observable effects are considered dead code and will be eliminated during optimization

Future improvements

Early Detection Framework：currently disabled an early detection system that could warn about potentially problematic shaders before DCE:

/// Check fragment shaders for meaningful output operations
pub fn check_fragment_output_validity(sess: &Session, module: &Module) -> Result<()>

This could be enhanced to provide warnings rather than errors for borderline cases