Ship a prebuilt ExecuTorch TensorRT delegate

[shoumikhin]

The problem

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

So a user who exports a model here cannot run it from a C++ application without building this
project first.

The change

Builds the delegate as a shared library, ships it in the wheel, and adds a CMake package so a C++
application can link it from an install.

torch_tensorrt/lib/libexecutorch_trt_backend.so    the delegate
torch_tensorrt/share/cmake/                        find_package support

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

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

import torch_tensorrt.executorch   # loads and registers the delegate

The delegate requires the exact ExecuTorch version it was built against, in CMake and in its
Python metadata. That is stricter than a lower bound on purpose: the two share C++ types that
are free to change between releases, so a mismatched pair fails at find_package time with a
clear message rather than at run time with something confusing.

It is off by default. Turning it on needs an ExecuTorch release that publishes the GPU wheels it
pins, so a release build that enabled it today would produce a wheel whose dependency no package
index can satisfy. Everything else is ready: the delegate builds, the CMake package exports, the
version pairing is enforced, and the Python import path loads it.

Before and after

BEFORE                                  AFTER

export a model through TensorRT         export a model through TensorRT
  works                                   works

run it from a C++ application          find_package(torch_tensorrt_executorch)
  build the delegate from source        target_link_libraries(app PRIVATE
  first, with the TensorRT SDK            torchtrt::executorch_backend)

Test plan

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

• find_package(torch_tensorrt_executorch) resolves and a C++ program links the delegate beside
  the ExecuTorch runtime and CUDA delegate
• the delegate survives the link and registers itself, even though nothing in the application
  references a symbol from it, which is what the retention options exist for
• a model whose graph splits across both delegates runs and matches the eager model, with both
  backend identities present in the program, so neither delegate is silently claiming everything
• the exact-version dependency resolves against an installed ExecuTorch package: an exact request
  for the installed version is accepted and a different version rejected
• importing the Python subpackage registers the delegate in the same process the C++ side uses,
  so there is one registry rather than one per consumer

[lanluo-nvidia]

this duplicates the delegate-runtime responsibility introduced by #4398,
but with a different distribution layout,
import/registration mechanism, CI path
Please rebase onto #4398 after it merges,
then either close this PR in favor of the runtime-wheel implementation or extract only the pieces that are still needed
and move them into the dedicated runtime package.
Also one of the major reason we ship a seperate delegate-runtime is that for the users which does not use executorch load feature, they do not need to install the delegate-runtime wheel, and it is a requirement from DLFW, they don't want introduce executorch dependency in the DLFW container image and they already complain that bundle the executorch related .so into our torch_tensorrt wheel which make it too big.