fix(matrix): Rebase positions by scanning MergeTree for handles

[DLehenbauer]

A POC fix/workaround for AB#7217

During reconnection, SharedMatrix attempts to reuse MergeTree's 'getContainingSegment()' to resolve past row/col positions to the current MergeTree segment + offset containing the row/col handle.

In practice, what I observed is that 'getContainingSegment(..)' may not resolve to the segment that contains the row/col handle, but to an adjacent removed segment. I believe this happens because removed segments have a length of zero, and therefore there are multiple segments occupying the same index.

For insertion semantics, this is not an issue: any of the segments at the desired index will serve as a usable reference point for 'findReconnectionPosition()'.

For replace semantics, this is a problem: we need to find the specific MergeTree segment that contains the row/col handle to determine if it has been removed.

This draft PR presents a low-confidence, quadratic-time work around that locates the segment + offset containing the row/col handle by linearly scanning the MergeTree. (See GH comments in 'Files changed' tab.)

[msfluid-bot]

⯅ @fluid-example/bundle-size-tests: +145 Bytes

Metric Name	Baseline Size	Compare Size	Size Diff
aqueduct.js	511.94 KB	511.98 KB	⯅ +44 Bytes
connectionState.js	680 Bytes	680 Bytes	■ No change
containerRuntime.js	244.63 KB	244.65 KB	⯅ +22 Bytes
loader.js	170.65 KB	170.67 KB	⯅ +22 Bytes
map.js	46.53 KB	46.54 KB	⯅ +11 Bytes
matrix.js	148.89 KB	148.86 KB	⯆ -31 Bytes
odspDriver.js	97.67 KB	97.7 KB	⯅ +33 Bytes
odspPrefetchSnapshot.js	42.63 KB	42.65 KB	⯅ +22 Bytes
sharedString.js	168.61 KB	168.62 KB	⯅ +11 Bytes
sharedTree.js	333.89 KB	333.89 KB	■ No change
Total Size	1.87 MB	1.87 MB	⯅ +145 Bytes

---

Baseline commit: f129eb61d115734d722d5d83970c8f962cf9ee64

Generated by :no_entry_sign: dangerJS against 4ec0250e54fc21fe9549e647f41226e387161c5a

[DLehenbauer]

(PR only intended to illustrate the bug.)