Consider changes to `NativeInput` ownership model

[syntheticmagus]

NativeInput, as presently implemented and used, is owned by a JavaScript context and merely exposed to app-level logic. This is an inversion of the pattern used by other components encapsulating platform behavior -- notably the Graphics component -- which are owned by app-level logic and merely exposed to JavaScript contexts. This pattern deviation causes a few differences in how NativeEngine is used, some of which I think have noteworthy downsides.

• Because NativeInput is not owned by app logic and sometimes does not exist, it is currently exposed to app logic (in App.cpp) using a raw pointer. However, the lifespan of the resource referenced by that pointer is controlled by JavaScript, not App.cpp. This creates a dependency circle where app logic is relying on state managed by JavaScript.
• Having NativeInput as a JS-level concept rather than an app-level concept may not scale for apps with multiple JS contexts as app logic would have to be aware of (and dependent on) NativeInputs owned by each of the JS contexts.
• Similarly, having NativeInput not be a View-level concept (mentioned in several comments) may make multi-view scenarios more difficult. I think this is already partly mitigated by additional concepts, but I'm hazy on the specifics.

In general, the NativeInput problem seems to have roughly the same shape as the Graphics problem, so it's possible that the same patterns being used for Graphics (a single long-lived Device object at the app level reflected through stateful DeviceContext instances within the JavaScript contexts) may be reusable for the NativeInput component.

[ryantrem]

I propose we have NativeInput follow the same pattern as NativeXR and NativeCamera, where there is a shared plugin object with a native and js “projection” of the plug-in api, and lifetime management is shared between native and js.