Add basic handling for specials

[Smith00101010]

Currently the Plugin only handles episodes within normal seasons and does not even try to find information for specials.

TVmaze handles specials different from other providers like tvdb. It does not give the specials an arbitrary episode number in season 0. In TVmaze there are two kinds of specials: significant and insignificant specials. Significant specials are important for the story of the show and can be included in episode lists at the appropriate point in the story of the show.

This means that we cannot handle specials in the same way as tvdb, as there are no episode numbers to use to identify the special. After talking to the TVmaze developer ( https://www.tvmaze.com/threads/4507/confused-with-how-to-name-specials-tv-maze-kodi-scraper?page=2 ) I arrived at this approach to identify any episode:

1. If a season and episode number is included in the filename, try to find the episode through that (e.G. "S01E04") (This is the current behavior)
2. If the filename contains a date in "yyyy-MM-dd" format, find all episodes with this airdate
3. If no or more than one episode was found check if the filename contains an TVmaze ID in brackets
4. If still no or more than one episode was found, check if any of the normalized possible episode names are in the normalized filename.

Users generally should include the airdate and/or the name for the episode to specify which special it is in a way that should make sense for other sources as well and not being too TVmaze specific.
Besides the file naming I have two points that I would hear other opinions about:

1. To identify the right position of a significant special within a season I must know which regular episodes come before and after. Right now, I take the easy road by requesting the show and all its episodes (including specials) which saves on requests (which are limited by requests per 10 seconds) but loads way more data than technically necessary. But I think we could also use this to our advantage by caching the last 5-10 shows requested, because in most use cases users will probably scan if they added a new library or a new season of a show which would mean we would only send two API requests to get all metainformation for all new episodes. Do you think that would make sense? Even with having 5 instances of the biggest show (ID: 10310) in RAM, and there are very few shows with nearly that many episodes, does not seem to consume more than 100 MB.

2. The Jellyfin way of handling specials, that should be placed in seasons, relies on the IndexNumber for sorting specials relative to each other. That can be important for cases like season 4 of Doctor Who, which ends with 5 specials where the order is important. As TVmaze doesn’t offer any numbering for specials, we have to invent our own. For now I implemented to just use the index of the specific special in the list of all specials. That works, but is not always stable, because an older special could be added at a later point in time and therefore the indexes would shift. What do you think about that? Any better ideas?

[Smith00101010]

After years it bothered me again that this plugin cannot handle specials so I rebased this pull request and made two changes related to the original implementation:

1. I started using the IMemoryCache for the episodes of a show with a sliding expiration of 2 Minutes and a absolute expiration of 15 Minutes. This significantly reduces the amount of REST requests that have to be sent, but only uses the memory as long as needed.
2. If users want (or have to) include the TVmaze ID in the file name I added a prefix to identify it as a TVmaze ID so it would have to be specified as [tvmazeid-12345]. This follows the way other providers do it and is similary documented at https://jellyfin.org/docs/general/server/media/shows/ for shows.

There is still the potential issue, that the calculated episode number of a special is not stable because a special that was aired before a previous scan date was added to the TVmaze database after that scan and therefore the episode number of specials could shift during a later scan. But I think this is a very unlikely scenario and also not that important if it should happen, because it only affects the order of specials.