Investigate loading schemas incrementally via ECSql

[ColinKerr]

@grigasp has run into performance issues when loading large schemas on the frontend for presentation: iTwin/presentation#601

Recent improvements have helped but for large schemas it's unlikely that an async incremental way to load schemas would improve startup time.

ecschema-metadata has the delayed promise abstraction around schema items but the implementation loads the entire schema at once. We should investigate an implementation that incrementally loads the schema using ECSql.

1. schema key + reference schema keys - This is enough to return the SchemaInfo for a schema
2. SchemaItem names - This is enough to create the schema item keys and hopefully construct the lazy loaded schema item
3. chunks of schema item bodies - We don't want to make an HTTP call for each schema item, that would be too many calls even for a small schema. We can investigate a single query that loads all dependencies for a given item. Loading all base classes for a class is easy to do, but what about all other dependencies?

Goals of this investigation

1. Is the current Lazy Load/DelayedPromise paradigm the correct one to use?
2. Can we efficiently incrementally load schemas?
3. Can we load enough to answer some important questions quickly then use other mechanisms to load the rest of the schema?
4. Suggestion how to proceed

[ColinKerr]

One possible implementation idea:

1. Load all schema item infos (a concept similar to SchemaInfo) which have item key plus key of referenced items
2. When a schema item is requested use SchemaItemInfo for that item to walk the tree of what referenced items are needed so a single request can be made to load all those items. Partially loaded schema knows what is already loaded so tree list of referenced items will only include those not yet loaded.

• Consider adding other items to request if request is small to further reduce requests for very flat schemas
• Consider loading units, koqs, formats, enums, structs or some of those on first load so list of referenced items doesn't have to go down to property level.
• Consider filling requests using ECSql ECDbMeta queries instead of in memory C++ schemas regardless of schema being loaded from frontend or backend

[rschili]

An alternative possible implementation idea:

1. Flatten the schemas. Like a "compiled" version of the schema. So each class has on its own all of its properties and infos attached.
2. Retain the names of where an info came from (like property.Origin.SchemaItemKey, property.KindOfQuantity.SchemaItemKey)
3. Retain base-class names so they can be looked up if needed

This should simplify loading single items, but it would be worse in scenarios where a full schema is needed.
Advanced version:

1. Support both, the flattened items, and fully loaded schemas
2. After a certain threshold we switch from the first to the latter and in-place replace the cached schema contents
3. Question: What to do across schema boundaries, do we still flatten referenced schemas?