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

[shoumikhin]

What this changes

An application that installs Torch-TensorRT and ExecuTorch as packages currently
has no way to link the ExecuTorch TensorRT delegate. torchtrt::executorch_backend
is created as an in-tree alias, and while the built library is installed, it is not
exported, so find_package finds nothing. The only way to use the delegate today
is to add this directory to another CMake project and build it from source.

This exports the shared delegate through a CMake export set with a relocatable
package config, so an application can do:

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

and get a working link with no source checkout.

Three smaller problems had to be fixed for that to actually work, each found by
building against an installed package rather than by reading the code:

1. The link-resolution chain looked for the ExecuTorch runtime as an in-tree target
   or a source checkout, but never as the imported target an installed package
   provides. Building the shared delegate against a wheel therefore failed asking
   for a source tree, which defeats the purpose of a delegate meant to resolve the
   runtime from the shipped shared library.
2. The package config installed into a directory named after the target rather than
   after the package, so find_package never looked there.
3. The export set names the concrete library, while an application wants a stable
   name that does not depend on which library flavor it got. The config now offers
   that name.

Only the shared delegate is exported. The static target's interface names
$<TARGET_FILE:...> to force a whole-archive link, which is a path inside the
build tree and cannot be meaningfully installed. The static target and its in-tree
alias keep working exactly as before, so existing source builds are unaffected.

Example and test

Also adds an example application that consumes the packages this way, plus a test
around it.

The example is deliberately not a variant of the existing reference runner: that
one calls add_subdirectory on an ExecuTorch source tree, so it never exercises
prebuilt libraries. This one resolves everything through find_package and
imported targets. It also takes a file of expected values and compares outputs
against them, so a wrong result fails rather than only being printed, and it can
allocate its input tensors in device memory to match how an accelerator
application feeds data.

The delegate registers itself from a static initializer, so an application
references none of its symbols and the linker is free to drop it. It was being
dropped, and the backend was then missing at runtime. The example names the
library on its link line so the reference is recorded. Note that an imported
target's location lives in a configuration-specific property, so a generator
expression is needed rather than reading IMPORTED_LOCATION.

What is verified

On Linux x86_64 and aarch64:

• The example configures and builds against an installed ExecuTorch package with
  no source checkout: exactly one CMake cache in its build directory and no
  ExecuTorch subproject.
• The output comparison passes on a matching reference and fails on a deliberately
  wrong one.

On Linux aarch64 with a GPU, additionally:

• The shared delegate builds against an installed ExecuTorch package and installs a
  consumable package: shared library, CMake config and targets, and headers.
• find_package(torch_tensorrt_executorch) resolves and yields
  torchtrt::executorch_backend.
• The example links it, and the library appears in the executable's dynamic
  dependencies, confirming the retention above.
• Export produces a program where TensorRT genuinely claims the graph, and at
  runtime the delegate registers and its initialization runs.

What is not verified

Executing a TensorRT-delegated program end to end still fails on this setup with a
serialization version mismatch:

TensorRTBackend::init: failed to deserialize TensorRT engine
Current Version: 240, Serialized Engine Version: 243

A TensorRT engine is version-locked. In the environment used here the Python
package that builds the engine and the system libraries the delegate compiles
against are different TensorRT major versions, and only one of them ships headers.
Closing that needs a single TensorRT providing both headers and libraries; it is
not a property of this change. The two device-execution tests are written and
collect cleanly, and they skip where the compiled runtime, a GPU, or an ExecuTorch
install with a CMake package is absent.