Remove unbounded cache sizes

[MichaelBelousov]

Unbounded caches in use are problematic:

• js Map in v8 (node) has a limit of 16.7M elements which has already been surpassed by Aspect counts in iModels
• large memory usage and garbage collector performance impacted by too many objects
• source element changes cache in federation-guid-optimization branch

Proposed changes:

• element remap table should be a temporary sqlite db, not a C++ data structure, so it can page to disk under memory pressure, and still be used in native code where geometry part remapping is done.
• aspect and element remap tables are probably, as the transformer uses them, good candidates for a custom data structure that stores "runs" (e.g. run-length encoding) of element mappings, (e.g. 7-10+10,15->16 === 7->17,8->18,9->19->10->20,15->16).
• the entire pending reference cache can be removed by storing a smaller cache of just the ids of elements that had unresolved references, and then after exporting everything else which will have inserted all targeted elements, then do the second transform + update that currently occurs as soon as the references are found.

Short term solutions:

• Use BigMap classes for aspects.

[MichaelBelousov]

worth noting, last time I tried using the integer based map in iTwin.js core for the transformer, it worsened performance 5-10% iirc. We need an integer based map though to do a naive run-compressed map. So need to think about this.

[MichaelBelousov]

this is done partially in the early-polymorphic-insert branch

EDIT: that branch now includes a CompactRemapTable class which does this remapping entirely

[MichaelBelousov]

the federation-guid-optimization branch also adds a new source changes cache which is unbounded