Initial commit of Anitopy integration changes

[MisterMcDuck]

Hello,

I've modified trackma to also leverage the anitopy library (python implementation of anitomy). I find that they both sometimes miss stuff but together have good coverage. Maybe this would be better as a feature rather than default?

Sorry for any sloppy coding, I don't normally write python code.

[z411]

Thanks for your work. Sorry for the late response. I am heavily considering this feature, but the way this is done (trying Anitopy then AIE) it would theoretically double the list scan times at worst. Which is why I'd prefer to choose one or the other; I'll do some testing and if Anitopy does a better job than AIE then I'd prefer to replace it completely. Or at the very least, let the user choose either.

[MisterMcDuck]

It's potentially even less performant, because if the path contains the folder name it also tries to run the detection logic on those as well (see https://github.com/z411/trackma/pull/473/commits/d05a8579561a2b428b2e3e47055d69bc03997b7b). I came at this change from a maximum detection perspective, but I can certainly see why you wouldn't want to introduce slowdowns for this process. The folder detection logic did help slightly, but it was minimal and generally only for non-standard release formats.

It's purely anecdotal, but in my experience Anitopy seemed to perform better with my collection. With that said, there were scenarios where Anitopy failed to detect the release while AIE did.

[FichteFoll]

I intended to build a test suite based on some examples from #413 when tackling the recognition issues I had, but I never got around to it. If anitopy as the more general approach could be enhanced with that, I belive it would make sense to try to find problems with it currently and fix them there.

Unfortunately, anitopy and anitomy need to be synchronized manually due to them being implemented in different languages, but the hope would be that both implementations would benefit from that.