Add NativeScope for single-base native types

[MridulS]

Provide a runtime-erased NativeScope base and native_scope decorator for generic identity keys around extension types that cannot support multiple inheritance. Preserve Scope-compatible specialization and add API coverage.

[SimonHeybrock]

Is this still necessary if we properly support 3.12 generics, see #237?

[MridulS]

Actually no PEP 695 isn't enough here, as it adds typing.Generic as a base class so we end up with multiple inheritance anyway.

>>> class Test:
...     pass
...
>>> class Apple[A](Test):
...     pass
...
>>> Apple.__bases__
(<class '__main__.Test'>, <class 'typing.Generic'>)

[SimonHeybrock]

In other words: Switching scipp to nanobind would make scipp incompatible with PEP 695 generics?

[MridulS]

Yeahh, but only if we are doing subclassing with the generics like class Data[T](sc.DataArray). Where else are we using this pattern?

A function like def func[T](data: sc.DataArray) is just fine.

[SimonHeybrock]

Yeahh, but only if we are doing subclassing with the generics like class Data[T](sc.DataArray).

My plan (from close to the time of first Sciline implementation) had been to remove all our use of the Scope (which we mostly considered a workaround) when we have PEP 695 generics. So the answer is kind of "everywhere".

[jl-wynen]

What about generic aliases like

type Data[T] = sc.DataArray

?

[MridulS]

type Data[T] = sc.DataArray works just fine, as there is no subclassing happening.

[SimonHeybrock]

type Data[T] = sc.DataArray works just fine, as there is no subclassing happening.

That sounds like a reasonable alternative then -- we do not actually want to subclass Scipp types.

[MridulS]

How do you want to proceed here then? Should we try to get #237 merged or test out the nanobind version with this PR first? I would prefer minimal and revertable changes first to make sure the nanobinded scipp works out of the box across the stack. I checked easy* code too and couldn't find a place where they do any multi inhertiance and neither in https://github.com/kinisi-dev/kinisi (@jl-wynen mentioned that it's built on top of scipp)

[jl-wynen]

I would prefer to update sciline and the ess packages first. Then we can test the nanobind update with the whole stack again.

[MridulS]

I would prefer to update sciline and the ess packages first

Yes but with this PR or #237?

[jl-wynen]

Some variant of #237
I think this PR won't be needed if / when we support the new type aliases.