Bump sdcv to 0.5.4 + a couple of PRs to fix it

[NiLuJe]

I'm not sure if it was actually broken for me before, but at least this one works on both Kobo & Android ;).

@pazos's hunch was nearly perfectly spot-on (my working theory is that it's the sizeof comparisons that were broken, quite likely because off64_t vs. ulong, and not the fstat call itself).

Split our existing patch in two, and submitted the sanest part of it upstream, because apparently I'd forgotten about it, and it happened to have been reported upstream.

---

This change is 

[NiLuJe]

OnePlus6:/data/user/0/org.koreader.launcher.debug/files $ LD_LIBRARY_PATH=./libs ./sdcv -v                                                                                                                                                                                                                                                                              
Console version of Stardict, version 0.5.4

(Actual in-app lookups work, that was just to double-check the version ;p).

[poire-z]

Possibly posted in not the right sdcv PR, but I just noticing this today.
When I lookup some word, on the emulator or my Kobo, I see this logged (so, even when not in debug mode):

Unknown dictionary: Dictionnaire de lâAcadémie Française, 8ème édition (1935).
Unknown dictionary: Petit Robert 2007
Unknown dictionary: XMLittre
Unknown dictionary: Wiktionary FR-FR
Unknown dictionary: Arramooz
Unknown dictionary: English-Arabic dictionary
[...]

It's some bit you get added upstream in Dushistov/sdcv@6e36e77
and may be it is logged because of our option to specify which dicts to use or ignore.

Everything seems to work, it's just noise in the logs, but still :)

[NiLuJe]

@poire-z: What's the commandline look like in this instance?

EDIT: i.e., do we pass an allow list or a deny list of dictionaries? (I seem to remember that we pass an allow list, but if we passed a deny list, I could just skip the warning for explicitly denied dicts in sdcv ;)).

Also, I seem to remember that we didn't/couldn't actually do anything with stderr because io.popen, and this is going to stderr, so I'm a bit puzzled as to how it actually ends up in the logs to begin with?

[NiLuJe]

Okay, yeah, it's an allow list, so we're stuck handling this on our side...

I'd be inclined to leave it as-is, because logging stderr makes sense, but if not, we'd "just" need to throw stderr to /dev/null in the shell command ;).

[NiLuJe]

Or... we could just patch that out in sdcv, because, while the warnings might make sense upstream, they don't really for us ;).