extmod/moductypes: Make the attr handler follow the native attr protocol

Summary

The attr handler of uctypes.struct (uctypes_struct_attr in extmod/moductypes.c)
doesn't follow the contract every other native attr handler honours: for an attribute
that is not a field of the struct it raises KeyError (via mp_obj_dict_get) instead
of leaving the result slot untouched so the caller can decide what to do.

This is invisible on a plain uctypes.struct, but leaks out as soon as a Python class
subclasses a native type with an attr handler — the scenario behind #18592.

The native attr protocol

mp_store_attr and mp_load_method_maybe (py/runtime.c) define the contract. The handler
gets a 2-element dest array:

• Store/delete — dest = { MP_OBJ_SENTINEL, value }:
  • owns the attribute → store it and set dest[0] = MP_OBJ_NULL (success);
  • does not own it → leave dest[0] == MP_OBJ_SENTINEL (caller raises AttributeError,
    or for a subclass falls back to instance __dict__);
  • operation genuinely invalid (e.g. wrong value type) → raise.
• Load — dest[0] == MP_OBJ_NULL: found → set dest[0]; not found → leave it NULL.

The key point: "attribute not recognised" is signalled in-band (sentinel / NULL), not via an
exception — exceptions are reserved for genuine errors. mp_obj_exception_attr,
complex_attr, range_attr, etc. all follow this.

What uctypes does instead

mp_obj_t deref = mp_obj_dict_get(self->desc, MP_OBJ_NEW_QSTR(attr));  // raises KeyError

For an unknown attribute this raises KeyError, conflating "not one of my fields" with a
genuine error.

Why it matters

1. Subclassing (Python subclass of native type with attr handler cannot properly store attributes #18592). Stores on a native subclass must be offered to the native
   handler first (else native fields are shadowed by __dict__ entries). With a conforming
   handler the generic code in py/objtype.c just checks the sentinel and falls through.
   Because uctypes raises, that code is otherwise forced to wrap the call in nlr_push/
   nlr_pop and guess from the exception type whether the attribute was unknown or a real
   failure — which adds an nlr frame to the hot path of every native-subclass store, is a
   heuristic (a setter legitimately failing with KeyError/AttributeError gets
   misread as "unknown" and silently redirected to __dict__), and is asymmetric with the
   load path (which never catches).

2. Inconsistent error type. A missing attribute on a uctypes.struct raises KeyError,
   whereas every other object (and CPython) raises AttributeError:

import uctypes, array
data = array.array("I", [0])
s = uctypes.struct(uctypes.addressof(data), {"value": uctypes.UINT32 | 0}, uctypes.NATIVE)
s.nonexistent          # -> KeyError      (expected: AttributeError)
s.nonexistent = 1      # -> KeyError      (expected: AttributeError)

Fix

Do a non-raising field lookup and return MP_OBJ_NULL when the field is absent, so the
standard machinery falls back / raises AttributeError:

mp_map_elem_t *e = mp_map_lookup(mp_obj_dict_get_map(self->desc),
                                 MP_OBJ_NEW_QSTR(attr), MP_MAP_LOOKUP);
if (e == NULL) {
    return MP_OBJ_NULL;   // not a field: let the caller fall back / raise AttributeError
}
mp_obj_t deref = e->value;

This lets py/objtype.c (the #18592 fix) drop the nlr_push workaround and just honour the
sentinel, makes store symmetric with load, lets genuine setter errors propagate as in
CPython, and works for any native type with an attr handler — not just uctypes.

Behaviour change

A missing attribute on a uctypes.struct now raises AttributeError instead of KeyError
(load and store). This is more CPython-like and consistent with all other objects; no test
in the tree depends on the old KeyError (checked against tests/extmod/uctypes_*).