Proposal for simple & easy to use keyboard-based menu navigation

<h2> In-game menu keyboard-based navigation, possible implementation </h2>

This PR is an example and potential beginning implementation of a keyboard (or joy, since its unified and uses same bindings) only menu navigation system. This will be useful if users wish to play with a controller with quick and logical navigation not using mouse emulation.

I sincerely recommend you check this branch out and compile and just play with it for one minute. It differs greatly from previous implementations of keyboard menu support.

<h3>TabList, the main class, how to use it:</h3>

Include a TabList in your class where you're going to have keyboard-navigable widgets. The order in which the items are accessed by the keyboard is implicit in the order you add them. 

Methods in tablist:
<ul><li><b>add(Widget*):</b> Adds your widget to the list. TabList will not destruct or otherwise claim ownership what-so-ever, you are still responsible for managing your widget. </li>
<li><b>remove(Widget*):</b> Removes your widget from the tablist. </li>
<li><b>defocus():</b> Removes focus from the currently focused Widget belonging to the TabList.
<li><b>logic():</b> This should be called as far up in your update method as possible and must be called for TabList to operate.  </ul>

<h3>What you should know as a widget implementer</h3>

There are three methods and one member that I've added to the base Widget class. The methods are all optional and have a default implementation. They are:

<ul>
<li><b>getNext() / getPrev():</b> is called when a user is iterating through widgets and reaches yours. these methods returns true when you are ready to release the up/down keys back to them. This allows you to implement internal navigation. You can find example usage of this in WidgetTextList. In TextList I don't actually release up/down (user must use left/right to escape) although I'm uncertain if this is the best practice or usage.
</li>
<li><b>activate():</b> Simple and straight-forward. This method is called when the user has focus on your widget and presses the activate key. I have altered WidgetButton to support this functionality.
</li>
<li><b>in_focus:</b> This is set to true when a widget is currently in_focus. This will allow the widget implementation to test for this and act appropriately.
</li></ul>
Other members which may eventually exist and be used: focusable (set to true or false depending on whether or not the widget is allowed to be "in focus") and captures_keys (set to true or false depending on whether or not the widget captures the entire keyboard, this will be useful in something like WidgetInput, and TabList would respect these flags, but this is currently not implemented.)

<h3>Note:</h3>

This is not by any means a final solution or final implementation. There are a lot of loose-ends, but I submit this as-is so that I might get feedback, criticism, or an otherwise go-ahead or "stop now!" before I spend the effort in implementing and supporting every widget we have so far.

Also, currently how GameStateLoad is working is with a manual implementation not using TabList. This is because the game slots are not implemented in terms of widgets. This is something that can be changed of course.

I realize it being named TabList may be confusing given that tab isn't even the supported key for navigation, and of course this can be changed also. I didn't feel it would be prudent to use tab, as this actually only reinforces the platform bias of the engine toward PC or platforms with keyboards. I kept all navigation binding-based.

Best regards,
Joe (Ninwa on IRC)