Cache tracker URL to hostname mapping

[glassez]

Unfortunately, the filtering algorithm used since #23452 has a noticeable performance degradation with an increase in the number of trackers per torrent. This is noticeable when switching the tracker filter if you have many torrents (several thousand), each of which has many trackers (several dozen).
This PR is designed to partially improve filtering performance by caching tracker hostnames to avoid re-parsing tracker URLs.

P.S. It's still not as productive as it used to be, so in the future I'll try to add some kind of data indexing to fix this (if it really bothers users).

[sledgehammer999]

Is it intended that the cache entries will never be invalidated during runtime?

[glassez]

Is it intended that the cache entries will never be invalidated during runtime?

It's hardly really necessary to care about invalidating them. I can't imagine suitable conditions for deleting an item from the cache:

1. The point is to have all the current trackers there, so the cache size limitation strategy doesn't make sense in this case.
2. If you want deleting a tracker that has been deleted from all torrents, then implementation of such a strategy would be a couple of orders of magnitude more complex than this, but in this case I would think of some other solution that, with a similar complexity of implementation, would bring greater performance optimization.

[Chocobo1]

What about let the cache become TorrentFilter class member? So it can be 'unloaded' when the filter is not used.