feat(react-components): CoreDM queries

[haakonflatval-cognite]

Type of change

Jira ticket 📘

https://cognitedata.atlassian.net/browse/BND3D-4541

Description 📝

Now - this was originally just a PR to implement the CoreDM-part of the Fdm3dDataProvider. However, a few cascading effects occured, making this monstrosity of a PR. I'll go through the relevant changes:

• Introduce typed queries. This is adapted directly from @christjt 's implementation in fusion: https://github.com/cognitedata/fusion/blob/master/libs/3d/src/api/datamodeling/sdk-extensions/queryNodesAndEdges.ts
  • This of course had a series of effects, due to requiring more explicitly typed calls. This especially lead to a long list of necessary changes in the Scenes-implementation, where I ended up doing a major refactoring to make the code more maintainable and usable type-wise.
• The FdmCadConnection type no longer uses nodeIds, but treeIndex. This type is used as a common grounds for an "asset mapping" for the legacy FDM-API and the new CoreDM. Since CoreDM does not really have a concept of nodeId, I decided to change it to treeIndex for future proofing. This may have performance implications for the legacy code, as I was forced to make another query translating between nodeIds and treeIndices. But all the better for CoreDM.
• Along with this, the caches now use treeIndex to as cache key, instead of nodeId, which also lead to a few changes.

I'll do my best to delegate the review across multiple team members

Remaining work:

• Implement remaining functions (3-4 of them?)
• Have proper data
• Test it all

How has this been tested? 🔍

In Fusion using this PR: https://github.com/cognitedata/fusion/pull/7854

Test instructions ℹ️

• Open in Fusion using PR mentioned above, enter project 3d-dev-aws
• In ThreeDSplitView.tsx (in fusion) and in ThreeDWidget, make sure that the RevealContext has the useCoreDm prop set to true
• See that all 3D functionality (listing, search, clicking in list, clicking in 3D, opening instance page, show mappings etc.) works

Checklist ☑️

• I am proud of this feature.
• I have performed a self-review of my own code.
• I have added PR type (Feat, Bug, Chore, Test, Docs, Style, Refactor) to the PR title.
• I have manually tested this for different scenarios (different models, formats, devices, browsers).
• I have commented my code in hard-to-understand areas.
• I have made corresponding changes to the public documentation.
• I have added unit and visuals tests to prove that my feature works to the best of my ability.
• I have refactored the code for readability to the best of my ability.
• I have checked that my changes do not introduce regressions in the public documentation.
• I have outlined any known defects / lacking capabilities in the contents of this PR.
• I have listed any remaining work that should follow this PR in the description or jira/miro/etc.
• I have added TSDoc to any public facing changes.
• I have added "developer documentation" in any package README.md that is related / applicable to this PR.
• I have noted down and am currently tracking any technical debt introduced in this PR.
• I have thoroughly thought about the architecture of this implementation.
• I have asked peers to test this feature.

[danpriori]

Nice work! Some few comments (which doesnt block it) but the rest LGTM at least.
However, of course Anders or someone else that has experience with the CDM needs to have a look on this.