Remove multi-list closest-match repair

[Borewit]

Resolves #207

[github-actions]

Build run (#6409266109, attempt #1) artifacts

[Borewit]

Happy with this change @touwys?

[touwys]

listFix()-2.8.1-14-057b1ce

Review the renegade (deep, batch) repair function #207

👉🏻 Resolved.

---

Additional observations:

1. Build-number added:

   

2. For interest's sake, I also ran the repair speed tests again, using the same playlist with 631 broken tracks, as before:

   Test 1: For this test, the FLAC plus MP3 Media Directories were added as media sources.
   Test 2: For this test, the FLAC directory is removed, leaving the MP3 directory as the only media source.

   REPAIR ACTION	Test 1: FLAC+MP3	Test 2: MP3 ONLY
   Find Exact Matches	1m 09s	0m 29s
   Find Closest Matches	5m 17s	2m 42s
   Find All Matches	6m 26s	3m 11s

   Notably, the aforegoing test results have grown worse by a considerable margin (>30%), over those of previous builds — all which were nearly consistent.

3. In addition, and this is a purely circumstantial observation, the PC memory (16GB RAM in this instance) usage appears to have worsened, too, while the playlist repair was in progress. Mouse pointer movement became rough/sticky/bumpy, unresponsive, and it is best to wait until all the broken track matches are found before continuing to multitask.

---

[Borewit]

Notably, the aforegoing test results have grown worse by a considerable margin (>30%), over those of previous builds — all which were nearly consistent.

The only explanation I have is that this is the effect of #209, but that you have not been able to measure that correctly because you experiences issue installing the corresponding build. I opened PR #207, which reverse the changes of #209.