Expose current tab key in Tabs widget

Currently, the Tabs widget does not expose the currently-selected tab to outside code. This is a problem for me, as I would like to be able to set the currently-selected tab programmatically (example: to open a new tab and switch focus to it immediately), and react to the user changing it (ex. to update the window menu with commands relevant to the current tab). What I'm unsure of is the best way to implement this change.

One option would be to store the current tab key in the application's data model with a Lens; this is the usual way to do things like this in Druid, but here it's a bit more complex because the Tabs widget cannot implement Widget<TabKey>; because it contains the body widgets it must implement Widget<ApplicationData>. That means that the Tabs widget couldn't use the normal LensWrap type, but instead would need to allow the application developer to configure a specific lens for the tab key - an unfortunate special-case in an otherwise uniform design.

Another option might be to expose a number of Command selectors that the Tabs widget could submit or listen for to notify/be notified about changes to the selected tab. This would also go against the grain of the existing design, and has the added downside that the tab key - the payload for these commands - would have to be type-erased, as the key type is determined by the tab policy. It would also be challenging for application developers to have multiple nested Tabs widgets behave correctly, where the normal reactive model makes that trivial.

A third option would be to extend the existing TabPolicy trait in some way. It could provide a lens, or act as a lens itself. It already does this to some extent, so this would fit in with the existing designs better than the other options.

Start by reading the Tabs widget, the TabPolicy trait, and the existing lens and command patterns described in the issue. Compare the proposed approaches, considering that Tabs contains body widgets and that nested Tabs must work correctly. Done means application code can read, set, and react to the selected tab key without type erasure or breaking the data-first design.