Need a plan for switching from SelectionManager in @itwin/presentation-frontend to @itwin/unified-selection

[grigasp]

The @itwin/unified-selection package replaces SelectionManager class and its related APIs. We need to come up with a strategy how the switch is going to happen.

Before deprecating the SelectionManager, we need to provide replacements for all existing use cases. Probably the trickiest one is property renderers / editors accessing current selection through UnifiedSelectionContext. The context can be provided by the property widget, but it needs to be defined in a package that's a common peer dependency of both - the widget and renderers / editors. At the moment they don't have such a peer dependency that knows about react and unified selection.

[grigasp]

After looking into this, I think the only way to provide a replacement for UnifiedSelectionContext is to:

1. Add an optional peer dependency of react to @itwin/unified-selection.
2. Provide React context provider and hook to provide/use selection storage.

For consumers this means:

• Applications that create selection storage can provide it to underlying components using the context provider. They'd have a direct dependency on the @itwin/unified-selection package.
• Components that need to access the storage, without having it in props, can use the useContext hook. They'd have a peer dependency on the @itwin/unified-selection package.
• Components that don't use the context, but use selection storage in some way, can continue to have direct dependency on the @itwin/unified-selection package, like they do today.

@iTwin/itwinjs-core-presentation, please review the above plan.

[grigasp]

Filed followup issues:

• unified-selection: Supply APIs to provide and use React context for accessing selection storage #829
• presentation-components: Deprecate unified selection related APIs #830
• Presentation: Deprecate selection-related APIs in @itwin/presentation-frontend itwinjs-core#7527