Read implicitron's own annotations via inspect.get_annotations

Summary:
`expand_args_fields` gated its whole member-processing pass on
`"__annotations__" in some_class.__dict__`. Under PEP 649 that entry is not in the
class dict until something materializes it, so on 3.14 the check was simply False,
no member was processed, and the pass that moves defaultable members to the end of
`__annotations__` never ran. The class then reached
`dataclasses.dataclass(eq=False)` with a defaulted `<name>_class_type` field ahead
of the non-defaulted `<name>` it replaces, which is a hard `TypeError` at class
construction.

`inspect.get_annotations` returns a class's own annotations — not a base's — which
is exactly what the `__dict__` lookup was expressing, and it behaves identically on
3.12. The in-place `del` / re-add on `some_class.__annotations__` further down is
unaffected: attribute access materializes and caches the dict on 3.14, so the
mutations stick and `dataclasses` sees them (verified on both interpreters).

325 canary failures in V58.

Reviewed By: bottler, ambv

Differential Revision: D115343017

fbshipit-source-id: 33f38dfac9f10c46b1f6b0e57f7005c9d7750dfa

pytorch3d/implicitron/tools/config.py

@@ -903,8 +903,12 @@ def expand_args_fields(
             processed_members.update(base._processed_members)
 
     to_process: List[Tuple[str, Type, _ProcessType]] = []
-    if "__annotations__" in some_class.__dict__:
+    # Only this class's own annotations, never a base's. Reading
-        for name, type_ in some_class.__annotations__.items():
+    # some_class.__dict__["__annotations__"] used to express that, but under
+    # PEP 649 the entry is not in the class dict until something materializes
+    # it, so on 3.14 the lookup silently found nothing and no member was
+    # processed at all.
+    for name, type_ in inspect.get_annotations(some_class).items():
         underlying_and_process_type = _get_type_to_process(type_)
         if underlying_and_process_type is None:
             continue