Replace "rollup" bundling with TypeScript project references

[kraenhansen]

What, How & Why?

This is another stab at fixing #5894:

• Deleted a usage of Rollup and related files in the SDK package.
• Introduced separate tsconfig files for each runtime environment (Node.js, React-Native)
• Introduced a realm/binding subpath export in the package.json to declaratively discriminate which of the generated native-*.mjs files should get imported from src/binding.ts, based on export conditions.
• Removed all the named exports from ./index.ts since they we're not actually accessible externally anyway. I hope to be able to introduce these in a follow-up PR adding ESM support for the package 🤞

If merged, I believe we can close #5853 as well.

Unsolved problems / considerations:

React Native test app fails to import the SDK

Performing a self-referring subpath import from our SDK isn't supported by Metro, when the package is co-located in the mono-repository. I've created https://github.com/facebook/metro/issues/1222 to track this. We might be able to provide a Metro configuration to work around this, but I haven't yet been successful in that.

No longer including @realm/fetch

Since we're no longer bundling, there's no easy way to include the @realm/fetch code with the package. We can probably just start publishing it to NPM, but it does add complexity and the risk of us forgetting to publish it or update the version in the SDK as it changes. If it worked, we might have included it as a bundled dependency. Perhaps we could do some symlink magic or find some other way to get it into the SDK package. Alternatively give in and use rollup, just for that. I haven't settled on this internally.

We're using stripInternal

We're relying on the stripInternal ts-config. This was already the case with Rollup, so it's not a new problem introduced by this PR.

The use of the option has the following caveat in the docs:

This is an internal compiler option; use at your own risk, because the compiler does not check that the result is valid. If you are searching for a tool to handle additional levels of visibility within your d.ts files, look at api-extractor.

I spent quite some time trying to configure api-extractor, as recommended, but the use of self-referring subpath exports is very confusing to the tool.

☑️ ToDos

• [ ] 📝 Changelog entry
• [ ] 📝 Compatibility label is updated or copied from previous entry
• [ ] 📝 Update COMPATIBILITY.md
• [ ] 🚦 Tests
• [ ] 📦 Updated internal package version in consuming package.jsons (if updating internal packages)
• [ ] 📱 Check the React Native/other sample apps work if necessary
• [ ] 💥 Breaking label has been applied or is not necessary