Investigate `@itwin/presentation-hierarchies` and `@itwin/presentation-hierarchies-react` merge

[saskliutas]

Investigate possibility of merging @itwin/presentation-hierarchies and @itwin/presentation-hierarchies-react packages into single @itwin/presentation-hierarchies package. API could be grouped by export paths into:

• /core - hierarchy building APIs
• /react - react state management and utilities APIs
• /react/stratakit - StrataKit based components to render hierarchy.

react and stratakit could be specified as optional peer dependencies and would be required for consumer to install only when UI part is used.

Possible problems:

• How to handle dependencies that re needed only for UI part?

[saskliutas]

Investigation summary: recommend not merging

Merging is technically feasible (subpath exports . / ./react / ./react/stratakit are already a solved pattern here, core stays React‑free at runtime). The blocker is the dependency question raised above.

The problem: to let a core‑only consumer avoid downloading UI deps, those libs must become optional peerDependencies (regular dependencies are always installed). But most UI libs (@tanstack/react-virtual, classnames, immer, react-error-boundary, react-compiler-runtime, @stratakit/icons) are internal — they don't appear in the public API. As regular deps we bump them silently. As peers, adopting a new breaking version means narrowing the range = breaking → major.

Trade‑off:

Approach	Core avoids UI download	No fake majors	Single package
Merged, UI as optional peers	✅	❌	✅
Merged, UI as regular deps	❌	✅	✅
Separate packages (status quo)	✅	✅	❌

Only true host‑singletons need to be peers (react/react-dom, and MUI adapters — already optional peers today). The internal UI libs don't, so promoting them is pure downside.

Conclusion: Separate packages is the only option that keeps both a React‑free core install and friction‑free internal dep bumps — the standard core/react split (cf. @tanstack/query-core + @tanstack/react-query). Recommendation: don't merge.