Fix for OnTileLoadComplete working only for the first instance of the event

[Mihoje]

If you want to have multiple GMapControls and want to add an event handler for both controls for OnTileLoadComplete it will not work. The event will only fire on one control's Core object.

This is because TileLoadQueue4, _tileLoadQueue4Tasks and _loadWaitCount are set to be static. Not sure why this is the case so this PR changes that, fixing the issue I've had with the events. Not the events fire independently.

[fallenmi]

This fixes event ownership, but it creates four permanent LongRunning workers for every Core. The worker loop blocks in TileLoadQueue4.Take() until IsAddingCompleted; neither CancelAsyncTasks() nor Dispose() completes the collection, supplies cancellation, or waits for _tileLoadQueue4Tasks. Closing a map therefore leaves every per-instance worker running and keeps its Core reachable. Repeated create/close cycles grow dedicated threads linearly.

On exact base 3a67916 and head 7b416d8, a six-core lifecycle probe produced one task list / four running workers at base versus six lists / twenty-four running workers on this head. After invoking the exact Dispose() method, all twenty-four head tasks were still running, zero of six queues were completed, and all six weak Core references survived forced GC. I used inert lock and matrix fields solely to bypass the repository's existing Windows-only kernel32 dependency on macOS; the compiled AddLoadTask and Dispose methods under test were unchanged. Both revisions build under net7.0; the existing net6.0 suite is baseline-identical here (14 failures on each revision from that same kernel32 dependency).

Please add an explicit per-Core shutdown path that unblocks and joins these workers (and defines reopen behavior), plus a repeated multi-control open/close regression, while preserving independent OnTileLoadComplete delivery.

Disclosure: I used Codex to inspect and build the exact revisions and run the focused lifecycle oracle; I verified the result.