Linked iModels

[pmconne]

It's not close to ready for review yet. Please don't nitpick the code - I'm looking for feedback on the general approach. The main new APIs are in IModelDisplayReference.ts, IModelDisplayReferences.ts, and IModelDisplayOverrides.ts.

This is a significantly pared-down version of the "scene-based viewer API" proposed a couple of years ago. It introduces the concept of "linked iModels" - i.e., permitting multiple iModels to be displayed and interacted with inside of a viewport. The goal was t o solve that problem in a way that is (1) minimally-disruptive to existing API consumers and (2) compatible with future iterations toward a more general "scene-based" API.

Viewport.iModel is superseded by Viewport.iModelRefs representing the set of iModels displayed within the view. Each iModel is represented by an IModelDisplayReference which specifies the subset (models, categories, elements) of the iModel to display. Each iModel reference can be individually styled, with its own symbology overrides, view flags, and so on. There is still always one "primary" iModel which cannot be removed and from which the view's coordinate system is derived. Any number of additional iModels can be freely linked to and unlinked from the view at any time. When we perform a pick against the view, the resultant HitDetail includes the iModel reference containing the picked element.

Viewport.view and Viewport.iModel still exist, and will remain for backwards compatibility. Internally, the primary iModel reference wraps the ViewState such that changes made via one API are propagated to the other. The aspects of the display style that affect the entire view can continue to be accessed via Viewport.displayStyle, but the aspects that apply to a specific iModel are better accessed through the IModelDisplayReference to which you want them to apply. Linked iModel references are not backed by a ViewState.

Tile tree references used to be instantiated from a ViewState. Now they are instantiated from an IModelDisplayReference.

I made a couple of possibly temporary breaking changes for the sake of making the new APIs intelligible:

• HitDetailProps combines all the "feature" stuff (element, subcategory, model, iModel reference, etc) into a single, required IModelFeature property. Previously you could have (or omit) any of these, which made no sense - a hit always originates from a feature.
• Setters for ViewState.categorySelector, ViewState.displayStyle, and SpatialViewState.modelSelector were removed. They always caused headaches with trying to listen for events, because whenever the underlying object was replaced you'd have to delete all your old listeners and register new ones. It's also pointless to replace the selector objects when you can just replace the contents of their model/category Id sets. For display styles, I added ViewState.cloneWithDisplayStyle if you really want to replace the entire style.

[pmconne]

Closing this PR for now to shut up the useless bot that just complains about lint rules we already enforce. Why can I delete human comments but not bot comments? Why must I dismiss each of its useless comments individually? Why is it enabled at all on draft PRs? Why can't I choose when and how to use AI?