Reimplement SortedSet for JS/native to improve performance

[m-sasha]

Proposed Changes

Reimplement SortedSet via min-heap + hashmap in the jsNative source-set.

This should give it the following performance:

• add, remove: O(logN), due to the heap.
• first: O(1), due to the heap.
• contains: O(1), thanks to the hash map

Previously the performance was:

• add, remove: O(N), due to the array.
• first: О(1)
• contains: O(logN), due to the binary search in the array.

Testing

Test: Ran the existing tests and added some new ones.

[MatkovIvan]

Looks good aside from minor style nitpicking. Correctness is checked by tests, so it should be good here.

But before merging, I'd like to see comparison before/after to make sure that additional memory consumption is justified.

[m-sasha]

I've run this test on uikitArmSim64 and wasmJs:

    @OptIn(ExperimentalTestApi::class)
    @Test
    fun uiTest() = runComposeUiTest {
        measureTime {
            println("Started")
            var size by mutableStateOf(1.dp)
            setContent {
                Box(Modifier.fillMaxSize()) {
                    Box(Modifier.fillMaxWidth().fillMaxHeight(fraction = 0.5f)) {
                        repeat(20_000) {
                            Box(Modifier.size(size))
                        }
                    }
                    repeat(20_000) {
                        Box(Modifier.size(size))
                    }
                }
            }
            repeat(10) { i ->
                size = (i + 2).dp.also {
                    println("Setting size to $it")
                }
                waitForIdle()
            }
        }.let {
            println(it)
        }
    }

The results are:

Target	Implementation	Time
uikitArmSim64	Old SortedSet	43 sec.
	New SortedSet	22 sec.
	New SortedSet*	23 sec.
wasmJs	Old SortedSet	16 sec
	New SortedSet	3 sec
	New SortedSet*	3 sec.
JVM	TreeMap	2 sec.

* with mutableScatterMapOf instead of mutableMapOf

Looking at the code, SortedSet is currently used only for MeasureAndLayoutDelegate.relayoutNodes, which I wouldn't expect to be large in normal usage. But someone out there could have abnormal usage, and if we can, why not provide them a faster implementation? The downside is code complexity, of course.

[m-sasha]

The disparity between wasmJS and uikitArmSim64 is suspect. It feels as if we have a badly-performing data structure in the native source-set.