Well, maybe we should step back and take a look at my motivations.  I
fundamentally believe that code should be:

* Easy to read for someone unfamiliar with the code base
* Easy to extend

The former means that projects can move forward with new effort and that future
selves can easily regain the context of the code.  The latter means that
features take time to implement proportional to their complexity.

So, when I think about a Menubar I expect it to be composed of Menus.  This
would lead to an initalization routine of the form

```javascript
_create: function() {
  this._initMe();
  this._initTheThingsIManage({ class: ComposingClass });
}
```

Uncoincidentally, the code in the menubar widget in this PR looks something
like that.  Given $.Widget being a means for encapsulating behavior (other
languages might call it being a factory for classes), I used $.Widget,
not because I wanted to create a widget, but because I wanted to have an 
instance which encapsulated this cognitive payload of work.

In constrast, when I first visited menubar code back in Nov 2012, the `_create`
method didn't look like the above, where there was a top level "outline" of
what was contained within( 0d30bda ). When I attempted to make my first bugfix
(what became 9f53e0a), I could not readily grasp the nature of what was going
on or where to inspect the erroneous close behavior.  A few lines should
suffice to express my point:

```javascript
  _create: function() {
    var that = this;
    this.menuItems = this.element.children( this.options.items );
    this.items = this.menuItems.children( "button, a" );

    this.menuItems
      .addClass( "ui-menubar-item" )
      .attr( "role", "presentation" );
    // let only the first item receive focus
    this.items.slice(1).attr( "tabIndex", -1 );

    this.element
      .addClass( "ui-menubar ui-widget-header ui-helper-clearfix" )
      .attr( "role", "menubar" );
    this._focusable( this.items );
    this._hoverable( this.items );
    this.items.siblings( this.options.menuElement )
      .menu({
        position: {
          within: this.options.position.within
        },
        select: function( event, ui ) {
          ui.item.parents( "ul.ui-menu:last" ).hide();
          that._close();
          // TODO what is this targetting? there's probably a better way to access it
          $(event.target).prev().focus();
          that._trigger( "select", event, ui );
        },
        menus: that.options.menuElement
      })
      .hide()
```

Maybe it's because I'm dimmer than the rest of you all, but having the code
document its intent (perhaps in function calls with (arguably) overlong names),
is very helpful for me when reading this code.  My cognitive focus faded
about the time `this.items.siblings` was invoked.

So these were my goals with this change. If you have any constructive feedback
about whether this PR moves closer to my stated goals I'd be glad to hear it.
Or, perhaps you can explain the superiority of the code style that I cited
above.  It may have virtues that I'm not readily seeing but I consider it a
smell when one method does *so very much*.