Fix mlir_translate TypeError + HostShimCAPI.h include path for a newer SDK

[akapoor3518]

What

Two small, independent fixes needed to get llama.cpp building clean against a newer SDK:

1. Submodule bump: bumps the ggml-tsi-kernel submodule to pick up a fix that removes
   a now-nonexistent mlir_translate field from the compiler-config JSON templates.
2. CMakeLists.txt: adds ${RUNTIME_DIR}/include/tsi-rt/shim to the tsavorite backend's
   include dirs.

Why

A build failure was reported:

TypeError: TXECompilerConfig.__new__() got an unexpected keyword argument 'mlir_translate'

Fixed at the source in the ggml-tsi-kernel submodule itself (currently open, undrafted,
awaiting review — not merged, see Scope below).

Fixing just that uncovered a second, separate issue: ggml-tsavorite/include/TestModel.h
does a bare #include "HostShimCAPI.h". That only ever resolved because a compiler
package directory happened to also carry a duplicate copy of this runtime package
header, on every SDK release up to now. A newer SDK's build no longer duplicates that
header — it only exists at ${RUNTIME_DIR}/include/tsi-rt/shim/HostShimCAPI.h, one level
deeper than the existing ${RUNTIME_DIR}/include include dir already covers. Added the
missing dir explicitly so it doesn't depend on the compiler package re-exporting runtime
headers.

Verification (real, on this exact branch, against the newer SDK)

build-fpga

• Full cmake --build succeeds, 100%. Real aarch64 ELF binaries produced (llama-cli,
  simple-backend-tsi).

build-posix

• Full cmake --build succeeds, 100%.
• Ran the resulting binary for real: produced real output and a real GGML perf summary
  showing nonzero TSI_KERNEL-RUN counts for ADD, MUL, RMS_NORM, MUL_MAT,
  SOFT_MAX, GLU — i.e. actual inference dispatched through the TSI OPU kernels, not
  just a clean link.

Sequence used to get here (documented for whoever picks this up next): reproduced the
exact mlir_translate failure first on an unmodified base against this SDK; confirmed it
disappears with fix #1 alone; hit HostShimCAPI.h next; root-caused and fixed with #2;
re-verified both targets build AND run clean from a fully fresh kernel/blob build (a stale
partial blob-build state from an earlier attempt had briefly masked an unrelated local
config issue on the verifier's own environment — not a code issue).

Scope / sequencing

• Depends on the upstream ggml-tsi-kernel fix landing first. Left as draft until that
  merges — the submodule commit pinned here is that fix's current branch-tip commit, and
  may need re-pointing once it merges (e.g. if squash-merged rather than fast-forwarded).
• This does not by itself fix all downstream consumers: some repos pin llama.cpp at a
  fixed release tag rather than tracking main, so they won't see this until a new
  release tag is cut that includes it and their own pin is bumped — their normal release
  process. Other repos vendor llama.cpp via a separate sync mechanism and will need
  their own vendor-pin bump once this lands, following the established pattern for prior
  vendor-pin-sync changes. Flagging both as the next real steps, not doing them in this PR.