feat(package/react): Add react-native support

[JohannesHome]

I tried using gqty in react-native and ran into the issue that there are dependency pointing to react-dom, leading to an issue with the metro bundler pulling web resources. There where two dependencies that pull in react-dom, the hooks from @react-hookz/web and the ssr implementation using react-dom/server.

This PR introduces react-native support for @gqty/react. I did the following updates:

• Added native entry points files like client.native.ts, index.native.tsx, ssr.native.ts, and native versions of the focus/online hooks so Metro resolves to RN-specific implementations that never import react-dom/server.
• Updated the build and the packages/react/package.json which now maps every export (., ./client, ./ssr/ssr) to the native bundle first and droped the wildcard ./*. bob-esbuild.config.ts rewrites dist/package.json so the published package keeps those native mappings at the top.
• Replaced @react-hookz/web with local hook helpers via hooks.ts (useRerender, useUpdateEffect, etc.) to avoid the peer dependency on react-dom. No behavioural change, just implementation detail. May need more testing.
• Added a short “React Native” section to the README describing the limitations (SSR still web-only, effects use AppState).

There are some risks in this approach as far as I can tell the removal of the wildcard could be a problem and would break anyone using @gqty/react/* imports. Also the custom implementation of the hooks maybe a risk.

As an alternative I could also create a new @gqty/react-native package in order to keep the react package as is. There is some code duplication of course, it maybe possible to move certain things into a shared package but will take more time.

[vicary]

@JohannesHome Given the scope I'll need more time to think it through, especially on the @gqty/react-native mainly because further dependencies on the web API is not safe from now on.

Rest assured, this PR will be merged in some way. If I ever wanted to split it up into smaller chunks in the process, you will be credited as Co-Author in those commits.

What do you think?

[JohannesHome]

@JohannesHome Given the scope I'll need more time to think it through, especially on the @gqty/react-native mainly because further dependencies on the web API is not safe from now on.

Rest assured, this PR will be merged in some way. If I ever wanted to split it up into smaller chunks in the process, you will be credited as Co-Author in those commits.

What do you think?

Thanks, you don't need to credit me if it adds unnecessary work.

Take your time to think it through.