fix: support TensorRT older than 10.15

[shoumikhin]

The problem

Two places in the runtime call TensorRT APIs that only exist in TensorRT 10.15 and newer,
without checking first. pyproject.toml declares a bare tensorrt dependency with no
minimum version, so an older but otherwise usable TensorRT fails in confusing ways instead
of reporting an unmet requirement.

This matters for platforms pinned to an older TensorRT. Some embedded and Jetson-class
configurations ship 10.13 and have no newer build available.

1. The C++ runtime does not compile.

core/runtime/TRTEngine.cpp:298: error: 'class nvinfer1::ICudaEngine'
    has no member named 'getAliasedInputTensor'

2. Exporting a model with a KV cache raises at export time.

AttributeError: module 'tensorrt' has no attribute 'KVCacheMode'

The second is the worse of the two. A compile error at least says plainly that the
toolchain is too old. This one appears in the middle of an export and reads like a bug in
the user's own model.

Why they are reachable

ICudaEngine::getAliasedInputTensor, INetworkDefinition::add_kv_cache_update and
KVCacheMode all arrived in TensorRT 10.15, together with the IKVCacheUpdateLayer that
produces the aliasing they describe.

For the export path, the validator that decides whether the KV fast path applies checks
only graph shape (rank, static dimensions, batch size, write dimension, single position).
Nothing in it consults the TensorRT version, so a qualifying graph reaches the emitter on
any version and then calls a name that is not there.

The fix

C++ side. One direct version check at the point of use, matching how the ScatterAdd
plugin include is gated in core/plugins/register_plugins.cpp:

  this->aliased_io = aliased_io;
// ICudaEngine::getAliasedInputTensor is not available before TRT 10.15 (e.g. Jetpack
// L4T builds), where an engine cannot report its aliasing and the build-time map is
// the only source of truth.
#if NV_TENSORRT_MAJOR > 10 || (NV_TENSORRT_MAJOR == 10 && NV_TENSORRT_MINOR >= 15)
  for (const auto& out_name : this->out_binding_names) {
    ...
  }
#endif

The loop only reconciles the build-time alias map against what the engine reports. On a
TensorRT that cannot report aliasing there is nothing to reconcile against, so the
build-time map is already the only source of truth.

Python side. emit_kv_cache_update_layer already returns None to mean "fast path
unavailable", and its callers fall back to the general scatter, so the guard reuses that
existing contract rather than adding a new one:

    if not hasattr(ctx.net, "add_kv_cache_update") or not hasattr(trt, "KVCacheMode"):
        logger.debug(
            "KV cache update: skipped — this TensorRT build has no KV-cache update layer"
        )
        return None

An older TensorRT gets the slower general scatter, which is correct, instead of an
exception.

Behavior on TensorRT 10.15 and newer is unchanged in both cases. The whole change is 14
added lines across two files, with no deletions.

Testing

Compiled the guarded C++ region against every TensorRT version available to me:

TensorRT 10.3   exit=0
TensorRT 10.13  exit=0     (fails without this change, with the error above)
TensorRT 10.15  exit=0
TensorRT 10.16  exit=0
TensorRT 11.1   exit=0

The control matters: with the check removed, 10.13 reproduces the original
has no member named 'getAliasedInputTensor' error, which confirms the gate is what fixes
the build rather than an unrelated include change. Also confirmed on an aarch64
Jetson-class device with system TensorRT 10.13.3.9, where the symbol is absent from the
installed headers.

For the Python guard, exercised the emitter both ways:

current TensorRT (11.1), layer available -> add_kv_cache_update is still called
simulated older build, layer absent      -> returns None, caller falls back

Existing tests: tests/py/dynamo/lowering/test_buffer_lifting.py passes, and
tests/py/dynamo/executorch/ gives the same result with and without this change (the
failures there reproduce on the unmodified branch, so they are pre-existing and unrelated).

A note on the declared dependency

If the project intends to require TensorRT 10.15 or newer regardless, declaring that floor
in pyproject.toml would turn both of these into an explicit dependency error. That felt
like a separate decision, so this change only makes the code work on what it can actually
support. Happy to add the floor instead if that is the preference.