[Feature Request - API] Display amount of files for an entry

[ThisIsntTheWay]

Feature

Add a new key to an entries metadata that displays the amount of files associated with said entry, e.g.:

{
  "id": 729,
  "name": "Sousou no Frieren",
  "files": 109, # <----
  ...
}

Motivation

Some shows, mostly unverified and externally imported ones, only have archives instead of uncompressed subtitles uploaded.
As such, the amount of files is often times much lower than the shows episode count.
(Of course, one also needs to take into account the amount of currently available episodes for currently airing shows)

Knowing the beforehand would make it possible to estimate if an entry only has archives uploaded. This could save one API call for every files query because we'd be able to make an educated guess whether to use the episode parameter or not.
(Many archives have names that seem to elude the episode number matching algorithm, so nothing would get returned)

Perhaps the key could even show the amount of archives vs uncompressed subtitles to facilitate an even more 'accurate' guess.

[Rapptz]

I get the motivation and I can agree that it'd be a nice feature to have but unfortunately due to technical issues this is way harder to implement than you might expected it to be. If the site was written in a dynamic language like Python this would be entirely trivial but it's not as simple here:

1. serde, the library I use for (de)serialization of JSON, does not support "synthetic fields". A synthetic field in this case is a field that is dynamic or computed and does not exist in the actual struct itself. I can work around this by implementing the Serialize trait myself, manually, but this is bad for maintenance and annoying to do.
2. utoipa, the library I use to generate OpenAPI spec, has the same exact limitation I mentioned above. Yes, I could implement their ToSchema trait manually but that would be way too annoying to do for little benefit and more maintenance burden.
3. Even if this was not the case, having this code path basically always have an underlying filesystem call is probably too expensive overall for the site. The site itself does internally use these models as well so having it present for everyone would be a lot of added cost.