iTwin workspace

[johnnyd710]

Attempt to address some of the problems from https://github.com/iTwin/itwinjs-backlog/issues/1898 and #7316

This PR adds a high-level API for persisting iTwin-scoped settings dictionaries through IModelHost, and aligns the iTwin workspace model with the existing iModel pattern.

await IModelHost.getITwinWorkspace(iTwinId); // analogous to `IModelDb.workspace`
await IModelHost.saveSettingDictionary(iTwinId, settingName, value); // analogous to `IModelDb.saveSettingDictionary`
await IModelHost.deleteSettingDictionary(iTwinId, settingName); // analogous to `IModelDb.deleteSettingDictionary`

Instead of requiring callers to:

1. find the iTwin settings container (and what if it doesn't exist)
2. initialize it
3. acquire and release write locks
4. discover or create an editable prerelease SettingsDb
5. open and close the db
6. handle abandon/cleanup paths

Why IModelHost?
I don't know if IModelHost is the right place for these APIs, but I ended up choosing it because (1) where else would we put it, there's no ITwin or ITwinDb equivalent to IModelDb? and (2) appWorkspace is already there.
Open to other suggestions

Why

We already have a simple API for the iModel workspace, and two methods to persist settings scoped to an iModel:

iModel.workspace;
iModel.saveSettingDictionary(name, dict);
iModel.deleteSettingDictionary(name, dict);

I'm introducing the "iTwin workspace" and attempting to match the iModel workspace's functionality. There are some key differences between the workspaces:

Workspaces

IModelHost.appWorkspace

• Application-scoped.
• The "source-of-truth" is the JSON schema files registered at startup.
• Holds app/default settings and containers.

IModelDb.workspace

• iModel-scoped.
• The "source-of-truth" is the dictionaries explicitly persisted into the iModel itself via saveSettingDictionary(...).
• The settings themselves stored in the iModels are iModel-scoped, but you can store pointers to iTwin settings, which can be used to snapshot or persist iTwin settings into the iModel when that is desired (i.e., to support ISO 19650 workflows - for example the latest iTwin workspace might be on v2.1.7, but there may be an iModel on the project given to a contractor that you want to stay on v1.1.0, ~v1.9.0, etc.)

IModelHost.getITwinWorkspace(iTwinId) (new)

• iTwin-scoped.
• The "source-of-truth" are the dictionaries persisted into the iTwin SettingsDb via saveITwinSettingDictionary(...).
• Useful for admin tooling and iTwin settings management without requiring an iModel.

[mergify]

This pull request is now in conflicts. Could you fix it @johnnyd710? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

[hl662]

Review from interactive code walkthrough — 5 suggestions, all non-blocking. Nice simplification overall 👍