Proof of concept: add support for opt-in inside-out keyboard event propagation

[GiGurra]

At present, it is not possible to (unless resorting to very unorthodox hacks) create inside-out event handler chains for keyboard events. This is useful in many applications (I ran into this with my first tview application), and is the default in the web world.

This PR is intended as a proof-of-concept rather than something to merge in its current form. Maybe there are better ways of solving this?

This PR creates an option where a user can opt-in to create inside out keyboard event propagation, by adding an additional captureFunctionAfter. The default such function just captures all events (to preserve tview's current semantics), but you can override this to add your own logic, filter out some for passing back to parents etc.

In order for this to be possible, a bool return value of the InputHandler() and WrapInputHandler functions indicating event consumption was added.

Existing widget/primitive specific input handlers have not been given any event consumption semantics, as that would change tview's semantic overall, plus different applications may wish to customize this, so consuming inside the default input handlers would (I suspect) break tons of applications.

This PR is perhaps more of a proof of concept than a finished solution - I'd just like to get the discussion going (and hopefully, if this PR or a variant of it, in the future gets merged I can remove my incredibly ugly hacks to emulate this i my own apps :))

Perhaps there are better ways of doing this? The base idea is - I really think tview would be a lot easier in many situations if inside-out event propagation was possible - if that comes in this form of a PR like mine, or totally different impl doesn't matter that much to me