Depend on c10 alone from aten_device (pytorch#22151)

### Summary

`aten_device.h` uses `c10::Device` and the c10 diagnostic macros, and it
uses
them only from inline functions. Plain c10 is all it needs.

The target asks for the `torch-core-cpp` external dep instead. In build
environments where that name maps to a library that also contains the
ATen
operator registry and the mobile interpreter, and where c10 is a
separate
library, those extra objects collide at link time with the copies the
application already links. The link then fails with duplicate symbol
errors on
things the header never touches, for example
`torch::jit::_get_runtime_bytecode_version()` and
`c10::TypeParser::lex()`.

This adds a `c10` external dep name and points `:aten_device` at it. The
dep
stays exported because `:aten_device` is header only and its consumers,
including `aten_bridge.h`, include the header directly.

Follow-up to pytorch#22146, which narrowed the same dep from `libtorch` to
`torch-core-cpp`. That removed the ATen operator registry but not the
mobile
interpreter, so one class of link collision remained.

### Test plan

In the open-source buck build `c10` maps to the same
`//third-party:libtorch`
target that `torch-core-cpp` and `libtorch` map to, so this is a no-op
here and
CI should stay green.

The difference was checked in a build environment where the three names
resolve
to different targets:

- An Android ATen-mode binary that failed to link with duplicate symbols
now
builds and produces a valid aarch64 executable. The same command at the
same
  revision fails without this change.
- A dependency query from `:aten_device` to the ATen operator registry
library
returns nothing after the change. The same query from `:aten_bridge`,
which is
unchanged, still returns a path, so the query does detect the dependency
when
  it is there.
- `:aten_bridge` and the ATen-mode `etdump_flatcc` build in all three
  environments where these names resolve differently.

Author: shoumikhin

extension/aten_util/targets.bzl

@@ -17,12 +17,14 @@ def define_common_targets():
             "//executorch/runtime/core/portable_type:device",
             "//executorch/runtime/platform:platform",
         ],
-        # aten_device.h needs c10::Device and nothing else. The full libtorch
-        # also registers every ATen operator, which duplicates the
-        # selective-build operator library in apps that reach this target
-        # through :aten_bridge, and :aten_bridge is portable mode.
+        # aten_device.h needs c10::Device and nothing else, and it only uses it
+        # from inline functions, so plain c10 is enough. Anything wider also
+        # brings in the ATen operator registry and the mobile interpreter. In
+        # build environments where those live in a separate library from c10,
+        # they collide at link time with the copies the application already
+        # links.
         exported_external_deps = [
-            "torch-core-cpp",
+            "c10",
         ],
     )
 

shim_et/xplat/executorch/build/env_interface.bzl

@@ -23,6 +23,8 @@ _EXTERNAL_DEPS = {
     "aten-core": [],  # TODO(larryliu0820): Add support
     # ATen native_functions.yaml file deps
     "aten-src-path": "//third-party:aten_src_path",
+    # Just the c10 core of PyTorch: Device, ScalarType, and the C10_* macros
+    "c10": "//third-party:libtorch",
     "cpuinfo": [],  # TODO(larryliu0820): Add support
     # Flatbuffer C++ library deps
     "flatbuffers-api": "//third-party:flatbuffers-api",