Fix O(n^2) performance bottleneck in CClientStreamer

[PrimelPrime]

Summary

Replace O(n) linear scans in CClientStreamer with O(1) hash-based lookups to eliminate quadratic performance degradation during bulk element creation.

Changes

• AddToSortedList: Replace ListContains O(n) duplicate check with Count O(1), and remove redundant sort insertion (DoPulse already sorts every frame)

• IsActiveElement: O(n) list scan -> O(1) set lookup

• FindOrCreateRow/FindRow: Replace linear m_ExtraRows list search with unordered_map for O(1) row lookups

• AddElements/RemoveElements: Accept optional unordered_set for O(1) duplicate checks during sector activation/deactivation

Motivation

Creating many elements in a loop especially via createObject() while the player/camera is at high altitudes -> z > 25000 caused severe performance issues, sometimes up to >35 seconds of load time depending on the camera position and this would increase drastically the higher up you would go.

As each new element passes through AddToSortedList which scanned the entire m_ActiveElements list for both duplicate checking and sorted insertion. With n elements, this results in 1+2+3+...+n = O(n^2) total work ~50 million operations for 10k elements.

The sorted insertion seems to be redundant since DoPulse already calls m_ActiveElements.sort(CompareExpDistance) every frame before ReStream consumes the list

Test plan

function testLoad()
    setCameraMatrix(0, 0, 50000)
    local objects = {}
    local t = getTickCount()
    for i = 1, 10000 do
        objects[i] = createObject(8558, 0, i + 5, 50000)
    end
    outputChatBox("Time: " .. (getTickCount() - t) .. "ms")

    setTimer(function()
        for _, o in ipairs(objects) do destroyElement(o) end
    end, 5000, 1)
end
addCommandHandler("testObj", testLoad)

Scenario 10k objects	Before	After
Camera at z < 25000	~150-200 ms	~150-200 ms
Camera at z > 25000	~2000-35000 ms	~150-400 ms

Load times can vary heavily dependant on system specs and camera position like already mentioned before

Checklist

• Your code should follow the coding guidelines.
• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.