OpenCoreKernel: surface silent kernel/kext processing fallback, close leaked KernelFile handle

[albert-mueller]

• OcKernelFileOpen only special-cased EFI_NOT_FOUND from
  OcKernelReadAppleKernel; any other failure (EFI_UNSUPPORTED,
  EFI_INVALID_PARAMETER, internal ReadAppleKernel errors) fell through
  silently to returning the unmodified kernel/kernelcache with no Kernel
  Add/Patch/Force entries applied, logged only at DEBUG_INFO which is
  compiled out of RELEASE builds. Now logged at DEBUG_WARN so this is
  visible in a normal verbose boot log.
• OcKernelFuzzyMatch never closed *KernelFile when a candidate
  kernelcache opened successfully but OcKernelReadAppleKernel failed on
  it, leaking one EFI_FILE_PROTOCOL handle per rejected candidate in
  directories with multiple kernelcache files.

This bug also causes kernel panics on T2 Macs.

[vit9696]

• File handle cleanup is indeed theoretically needed. Thank you! I applied this change in master, though without pointless NULLing and a wall of comments AI-tools like to leave, decreasing human readability.
• As for the log message, to be honest, there are many situations you cannot diagnose without a debug build. If there is an I/O failure like this, something in the UEFI env is very broken, and it will unlikely help to print just this message in RELEASE builds.