[UDFS] Initialize all local variables to prevent 0xCCCCCCCC in MSVC debug builds

[Zero3K20]

MSVC debug builds fill uninitialized stack variables with 0xCCCCCCCC. In kernel drivers this is dangerous: an uninitialized BOOLEAN reads as TRUE (non-zero), causing _SEH2_FINALLY cleanup blocks to release locks or resources that were never acquired.

Changes

• NTSTATUS variables: initialized to STATUS_SUCCESS
• BOOLEAN flags: initialized to FALSE
• ULONG counters/sizes: initialized to 0
• Pointer variables: initialized to NULL

Covers 31 files across the driver (cleanup.cpp, create.cpp, fileinfo.cpp, fscntrl.cpp, misc.cpp, read.cpp, write.cpp, udf_info/dirtree.cpp, udf_info/extent.cpp, udf_info/mount.cpp, udf_info/udf_info.cpp, and others) as well as the support libraries in the Include/ directory (Sys_spec_lib.cpp, phys_lib.cpp, regtools.cpp, mem_tools.cpp, string_lib.cpp).

Notable bug-class fixes

Acquisition flags in _SEH2_FINALLY blocks — if 0xCCCCCCCC, these appear TRUE and release resources never acquired:

// Before
BOOLEAN Acquired;
Acquired = UDFAcquireResourceExclusiveWithCheck(...);
// ...
_SEH2_FINALLY {
    if (Acquired)  // 0xCCCCCCCC == TRUE if exception before assignment
        UDFReleaseResource(...);
}

// After
BOOLEAN Acquired = FALSE;

UDFSetRenameInfo counters — DirRefCount, FileInfoRefCount, IgnoreCase, UseClose used in loop logic before guaranteed assignment.

Include/ support libraries — NTSTATUS return values, BOOLEAN status flags, ULONG loop/search variables, and pointer variables in phys_lib.cpp, regtools.cpp, mem_tools.cpp, Sys_spec_lib.cpp, and string_lib.cpp.