Alright, here's the idea (more clear after one year:)

- will need to expose getBytesLoaded() interface
- will need to expose canRead(x) interface
- will need to expose canSeekTo(x) interface

With the three above (which are basically 2, as canRead
could be implemented in terms of canSeekTo), we'll have non-blocking reads available.

Now, the first advantage is that we don't need to change
users of it. Users that just ::read() will block, while
users we'll update will be smarter.

In the current situation, the smarter users use a LoadThread,
which embeds a tu_file and provides those interfaces. This is
a waste for filesystem files, which wouldn't be needed if tu_file
supported that natively: filesystem-based tu_file would implement those calls w/out needing a thread.
Also, if tu_file supports that natively, the curl_adapter might
use a single thread to load data from any instances, using a single select-based loop and sleepign most of the time.

Marking this as the first 20% progress.

Note that the current NetSTreamFfmpeg is not using a loader thread yet because doing so would take changing a lot of code
from tu_file to LoadThread, and that isn't as easy as expanding
the tu_file interface directly...