Cache Matroska subtitle tracks across track switches

[HellbringerOnline]

Summary

This PR reduces repeated reads of the same Matroska file when working with embedded subtitle tracks.

The main change is in MatroskaFile.GetSubtitle(...): the first subtitle extraction now scans the Matroska clusters once and caches subtitle blocks for all subtitle tracks in memory, keyed by Matroska track number. Later requests for any subtitle track on the same MatroskaFile instance reuse that cache instead of scanning the file again.

Why

The Pick Matroska track dialog previews subtitle tracks by calling GetSubtitle(...) when the selected row changes. Before this change, MatroskaFile only cached the most recently requested track. Selecting track A, then B, then A again caused another full scan of the MKV for A. The same repeated read also showed up when the selected track was loaded after previewing it.

This is especially noticeable with large .mkv files because every track switch can turn into another read through the container.

What changed

• Replace the single-track Matroska subtitle cache with an in-memory cache for all subtitle tracks in the current MatroskaFile instance.
• Collect subtitle blocks for all subtitle tracks during the first cluster scan.
• Keep the public GetSubtitle(int trackNumber, LoadMatroskaCallback progressCallback) API unchanged.
• Remove duplicate GetSubtitle(...) calls for HDMV TextST preview/export paths where the subtitles list had already been loaded.

The cache remains scoped to the lifetime of a MatroskaFile instance and is released when that instance is disposed.

Known remaining behavior

There is still another related scenario outside this PR: after selecting an image-based MKV track and opening the OCR window, pressing Edit/Export opens Edit image-based subtitle. That path currently passes both the source file name and the already extracted OCR subtitle data to BinaryEditViewModel, but BinaryEditViewModel reloads the file when a file name is present. For multi-track or large MKV files this can show Pick Matroska track again and trigger another Matroska read.

That behavior is significant for large files, but it is a separate handoff/lifetime issue between the OCR and BinaryEdit windows. This PR keeps the scope limited to improving repeated reads within a single MatroskaFile instance.

Validation

Ran locally:

• dotnet test tests\\libse\\LibSETests.csproj --no-restore

Also checked on the newer upstream-based branch before preparing this fork-compatible PR branch:

• dotnet test tests\\libse\\LibSETests.csproj --no-restore
• dotnet test tests\\libuilogic\\LibUiLogicTests.csproj --no-restore
• dotnet build src\\UI\\UI.csproj --configuration Release --no-restore

On this older fork base, tests/UI/UITests.csproj and src/UI/UI.csproj hit existing package/project setup issues unrelated to this change (xUnit v3 OutputType and missing UI package references without refreshing the lock/restore state), so I did not include lockfile updates in this PR.