[HLSL] Local resource variables are exempt from Clang's uninitialized-variable analysis

Clang's CFG-based uninitialized analysis correctly diagnoses both the definitely-uninitialized and conditionally-uninitialized cases for scalars, but HLSL resource types don't participate in it, so equivalent code compiles silently. This is worse than the scalar case: an uninitialized resource has no binding for the access to lower to, so the shader cannot work, and the optimizer folds the undefined path away, which can make it appear to work.

```hlsl
RWByteAddressBuffer GBuf : register(u0);
[numthreads(1,1,1)]
void main(uint3 Tid : SV_DispatchThreadID) {
int A; // warns: -Wuninitialized
int B; // warns: -Wsometimes-uninitialized
if (Tid.x == 0) B = 7;
RWByteAddressBuffer C; // silent
RWByteAddressBuffer D; // silent
if (Tid.x == 0) D = GBuf;
GBuf.Store(0, A + B);
C.Store(4, 1);
D.Store(8, 2);
}
```

Only A and B are diagnosed. We expect similar warnings for C and D, however, matching the scalar behavior. The likely cause is that resource types are class types with an implicit default constructor, which the analysis treats as initialized.

Start by tracing Clang's CFG-based uninitialized analysis for HLSL resource types and how their implicit default constructor is classified. Compare the scalar A/B cases with resource C/D in the reproducer. Done when equivalent definitely- and conditionally-uninitialized resource variables receive matching warnings for the shown HLSL code.

Written by the indexing model from the issue text.