Let a C++ application use the ExecuTorch TensorRT delegate from an install

[shoumikhin]

Torch-TensorRT can already export an ExecuTorch model that runs through TensorRT. What it cannot
do is give you a prebuilt delegate: the runtime piece that actually executes the TensorRT parts
of the model has to be compiled from source, which means a full C++ build with the TensorRT SDK
installed.

This adds a prebuilt delegate and a CMake package for it, so a C++ program can link it from the
installed wheel.

What you get

before:
  export a model through TensorRT       works
  run it from a C++ program             build the delegate from source first

after:
  torch_tensorrt/lib/libexecutorch_trt_backend.so.2   the delegate, prebuilt
  torch_tensorrt/share/cmake/                         so find_package works

How you use it

In your build, alongside the ExecuTorch runtime:

find_package(executorch REQUIRED)
find_package(torch_tensorrt_executorch REQUIRED)
target_link_libraries(my_app PRIVATE
  executorch::runtime
  executorch::cuda_backend
  torchtrt::executorch_backend
)

In Python, importing the subpackage loads the delegate so it registers itself:

import torch_tensorrt.executorch  # loads and registers the delegate

Version pairing

A delegate built against one ExecuTorch release cannot be assumed to work with another, because
the two share C++ types that are free to change between releases. So the delegate records the
ExecuTorch version it was built against and requires exactly that version, both in CMake and in
its Python metadata.

That is stricter than a normal lower bound, and deliberately so: a mismatched pair fails at
find_package time with a clear message rather than at run time with something confusing.

Status

The prebuilt delegate is off by default. Turning it on requires an ExecuTorch release that
publishes the GPU wheels it pins, which is not available yet, so a release build that enabled it
would produce a wheel whose dependency no package index can satisfy. Once those wheels publish,
enabling it is a build-flag change plus the release job wiring.

Everything else here is ready: the delegate builds, the CMake package exports correctly, the
version pairing is enforced, and the Python import path loads it.

Tested

Built the delegate on Linux aarch64 with a Jetson device and on x86_64, then from a clean
environment with no source checkout reachable:

• ran find_package(torch_tensorrt_executorch) and linked a C++ program against the delegate
  alongside the ExecuTorch runtime and CUDA delegate;
• confirmed the delegate survives the link and registers itself, even though nothing in the
  program references a symbol from it;
• confirmed a mismatched ExecuTorch version is refused at configure time rather than accepted;
• confirmed importing the Python subpackage loads the delegate, and that the export path still
  imports when no prebuilt delegate is present.