Add support for file based stubs and improve support for disc stubs

[phate89]

This is a different version of #551.

It's the first time I go deep in Kodi code so please be patient with me.
I tried to hide stub files under Kodi vfs in efile:// urls. I used something similar to a mix of Zip and special protocol file for efile stubs.
I also improved disc stubs handling. Now theyworks similarly to iso files. Both they should work better now (thumbs creation, resume support, watched state, right info, episode bookmarks etc etc).

I also removed several CFileItem creations only to get to IsDiscImage with a specific URIUtils method (called also from CFileItem).

I have 3 doubts:

1. I used FileDirectoryFactory to translate to efile links because is the only way I could find to store an efile:// in the database so I could both get access to the real efile file and the destination one. There are better solutions?
2. I'm not sure if I have to disable thumbs creation for efile stubs or not. right now is disabled.
3. (unrelated) In DVDInputStreamBluray before kodi was checking for ".iso|.img" extensions. It's the only place where it doesn't use IsDiscImage that checks also for .nrg files. I replaced it with IsDiscImage. There's a different path for .nrg files I missed?

Needs xcode sync

[phate89]

Is this have a chance to get in kodi core?

[tamland]

Is "efile" a commonly used name for this sort of thing or something you invented?:) What does the e stand for?

[phate89]

@tamland thanks for the review.
I agree it's not great to read everytime. The problem is that I can't store it in the database because it needs the xml file there. I can store it in the class but most checks create a new class so it doesn't help. I didn't find a better solution. Is there something in kodi for this kind of caching?
Performance wise it seems it doesn't slow down since with the heaviest task (reading the file) it uses the actual file directly.
About the name I didn't created it. I took #551 pr and tried to fit in kodi vfs. Now they works quite better and support resuming, episode bookmarks, watched state etc etc
I didn't change the names but now this names didn't make sense to me too. Probably something like "media stub" is better..

[tamland]

Twice then? Once for reading the message when displaying the dialog, once when resolving the path. Remember, it can live on network. I'm not very familiar with these parts, so others will have to comment. Maybe look at how .strm files are handled wrt reading?

[phate89]

I checked strm files like @tamland suggested but they are simply playlists. They work similarly to how disc stubs work right now changing the path before to start to play so no resume support, no info, no automatic watched state etc etc.
I did some change and now with my last FileItem change if the file exists it opens the file only twice.. It doesn't seems it's too much of a compromise.. Of course if you have suggestions to avoid that i'll gladly consider them..

[da-anda]

@phate89 any plans to resurrect this PR?

[jenkins4kodi]

@phate89 this needs a rebase

[MartijnKaijser]

I will close this PR. If there's interest please open a new one (with required changes if needed).