Adopt the upstream split-backend linking once executorch#21849 lands

Once pytorch/executorch#21849 lands, move RNE to an ExecuTorch release that carries it and adopt the supported arrangement rather than the one we build today.

Why this needs a deliberate step

We already ship split backend .so files, but our libs are built from the PR branch and the topology we rely on is not the one the upstream AAR uses. Ours works because libRnExecutorch.so links libexecutorch.so and the backend together, so they land in one lookup group with the runtime first. The shipped v0.10.2-libs backends confirm the dependency is implicit:

libxnnpack_executorch_backend.so  NEEDED: libm, liblog, libdl, libc     # no libexecutorch
  GLOBAL DEFAULT  executorch::runtime::register_backend(...)            # its own copy

The merged version links the backend against the runtime instead, so register_backend and get_pthreadpool become UND and resolve through DT_NEEDED. That is load-order independent, and libexecutorch.so gains a matching SONAME.

What to check when we bump

• android/CMakeLists.txt still links the backends explicitly. With DT_NEEDED in place this is no longer what makes registration work, but it is still what gets them packaged.
• Confirm the new backends are UND for register_backend, not defining it: llvm-readelf --dyn-syms libxnnpack_executorch_backend.so | grep register_backend.
• Confirm DT_NEEDED names libexecutorch.so and that the SONAME of our staged runtime matches, or the loader looks for a file the APK does not carry.
• Re-check the thread pool: get_pthreadpool() must resolve to the runtime's singleton, otherwise XNNPACK runs on a second, unconfigured pool and our thread-count tuning silently does nothing.
• Run a delegated model on device per backend. A backend registering into the wrong table fails as DelegateNotFound at execution, not at load, so a smoke test that only loads the library will not catch it.

Related

• Upstream PR: pytorch/executorch#21849
• Our current libs: v0.10.2-libs