pywebnn: catch up with RustNN changes or generate directly via nanobind? #318

pywebnn had many APIs before RustNN had them. Now RustNN catched up, but pywebnn still retains its own logic ( rustnn/torch2webnn#3, rustnn/pywebnn#24)

We should either:

• slim down pywebnn and remove logic we now have in RustNN (e.g. GraphInfo building, validation) + add some simple adhoc python buffer protocol handling (pyo3 doesn't support this directly, also not well via pyo3)
• direct generation of python api, e.g. via nanobind from c++ bindings (has built in dlpack+buffer protocol support)