Better menu item injection

[pgaskin]

closes #43

[pgaskin]

So far, this works (and it's stable), but the code needs a lot of cleanup (it's still a mess from when I was trying different techniques), which I'll be doing tomorrow or the next day. You can still leave comments now if you have any questions or suggestions.

I'm probably going to see if I can do something about the fact that this is slightly more fragile than the old method. It should still work on all firmware version, though (but I'd appreciate it if anyone can test this on older fw versions).

[pgaskin]

I think this is as clean as it's going to get for now.

[pgaskin]

And a quick note about where this is more fragile than the old method:

• It depends on the AbstractMenuController pointer being valid for the duration of the QMenu's existence (which currently is the case, and fits with how the rest of libnickel uses it, but we won't be able to gracefully fail if it ever changes, which it probably won't while keeping the current design of nickel). And, if it ever changes, I do have a few ideas on how to handle it (the Qt type system is quite convenient).
• If the behavior (before, it was just the return value we cared about, not the behavior) of the function which creates the menu items changes (either regarding touch events, the number of widgets added to the menu, or the return value), it will either stop working silently (the items will not work or will be in the wrong order), or it will crash when the menu is opened (rather than when the menu is being created, but this could be seen as an advantage...).
• It depends on signals, which increases the complexity, but this is essentially never going to break since we're depending on core signals, not ones from libnickel (if it breaks, it will silently stop adding menu items, but it won't segfault).

On the whole, these additional points of breakage are irrelevant since they're unlikely to change without the symbols also changing (which will be caught by NM). This probably won't happen unless nickel is redesigned.

---

P.S. And, the points where the old method is fragile (which also apply to this one) is:

• The hooking (but this is not going to break without drastic compiler changes).
• The symbol names for the action creation and the separators (but this is true of all mods, and it will fail gracefully).
• The return types (but this a bit more lenient and is unlikely to become incompatible without a redesign involving a symbol name change too).
• The translations for the injection point (but there's not much reason for that to change, and it won't affect English if it does, plus it's possible to extract it at runtime if it becomes unpredictable).

---

In other words, NM won't be much more fragile than it was before, and it wasn't that fragile to begin with (there's only one or two places it could segfault, and the possibilities for silent errors are more likely to cause a non-silent one first).

[shermp]

I'm afraid I can't offer much of a review (I'm still a bumbling idiot when it comes to Qt and C++), but I couldn't see anything obviously wrong, and my Kobo didn't break.

[NiLuJe]

Yup, nothing imploded on my end either ;).

[pgaskin]

OK, I'll merge this once I implement #25 and release v0.1.2. Then, I'll work on #42 (which should be pretty simple now).