Fix SIGSEGV in AddRequiredMemoryFences when loop has no exit blocks

[maxious]

FindPostDominator lambda dereferences blocks.begin() without checking
if the container is empty. When getUniqueExitBlocks() returns an empty
vector (e.g. for infinite loops or loops whose exits were optimized
away), this causes a segfault.

Fix: Guard FindPostDominator with an empty check and skip the
exit-block post-dominator computation when there are no exit blocks.
In that case, keep the post-dominator of the unfenced SLM stores
themselves, which is still a correct (conservative) fence placement.

Also add LLVM_DEBUG diagnostics for unfenced block count, exit block
count, and fence insertion location to aid future debugging.

Reproducer

The bug is triggered by SYCL kernels that write to SLM (shared local
memory) and synchronize with item.barrier() (without an explicit
fence_space::local_space argument) inside a loop. IGC's IsSlmFence()
does not recognise the barrier as an SLM fence, so the
AddRequiredMemoryFences pass attempts to insert one at the loop's exit
blocks. When the loop has no unique exit blocks (after optimisation),
getUniqueExitBlocks() returns an empty SmallVector and
FindPostDominator dereferences blocks.begin() on it → SIGSEGV.

The crash depends on the IGC optimiser's inlining/loop decisions and
is most reliably triggered when many kernels share one large SPIR-V
module.

Minimal kernel pattern that provokes the pass:

  // SLM store
  tile[tid] = src[row * K + k0 + tid];
  // barrier without fence_space — not recognised as SLM fence
  item.barrier();
  // ... accumulate from tile ...
  item.barrier();

Backtrace (with debug symbols):

#0 operator()<SmallVector<BasicBlock*,8>>  AddRequiredMemoryFences.cpp:168
#1 IGC::AddRequiredMemoryFences::runOnFunction  AddRequiredMemoryFences.cpp:181
#2 llvm::FPPassManager::runOnFunction
...
#5 IGC::CodeGen  OpenCLKernelCodeGen.cpp:2336