Option to specify the tab list selector

In #4877 there was a request to allow specification of the selector for the list instead of the hardcoded "ol, ul". The reason was because it was using .children instead of .find and the requester wanted to use nested markup. Unfortunately this does have a side effect on a use case involving the third party UI.Layout plugin whereby it's desirable to have a nested UL ahead of the UL that's to be used as the tab list, so it would be more useful to be able to specify the selector!

To give some background - in the UI.Layout plugin it is possible to have the tab widget be a pane and have just the tab content scrolled - UI.Layout has special support for that by flagging that the "tab" part is header and the "panes" part is content. It is also possible to add additional header and footer sections into a pane, which for this simple case would go inside the tab container element at the same level as the tabs.

Unfortunately with the selector for the tabs widget being fixed to pick up the first UL or OL it means if you have additional header content in the pane then you can't have a UL or OL in there or it gets tabified!

To give an example of the structure I'm wanting to use:

<div id="mytabs" class="ui-layout-center">
  <div class="ui-widget-header">Some header content
    <ul class="notTabHeader"><li>Some list in the header</li></ul>
  </div>
  <ul class="tabHeader">
    <li><a href="#atab">A Tab</a></li>
  <ul>
  <div class="ui-layout-content">
    <div id="atab">The pane content</div>
  </div>
</div>

Now under UI.Layout I can use this structure easily to get it to set out the header and tabs first and give them enough vertical space so they don't scroll and then the panes will be scrollable if necessary, but if I include a UL in the header then the tabs widget will find that rather than the later UL.

An alternative to allowing the selector to be specified as an option would be to maybe give priority to child ULs and fall back to searching for the first UL regardless of whether it's a direct child or not:

this.list = this.element.find( "ol,ul" ).eq( 0 );

Could become one of:

this.list = this.element.children( "> ol, > ul, ol,ul" ).eq( 0 );
// or
this.list = this.element.children( "ol,ul" ).add( "ol,ul", this.element).eq( 0 );

This would break backward compatibility only if someone has a non-nested UL (i.e. direct child UL of the tab element) that they don't want to be used as the tab list, which would seem to be extremely unlikely!

I understand that my request might be a bit of an unusual case - I can work around the problem by using nested layouts - it just seems a shame to need to do that extra plumbing just because the tab widget is fixed to always use the very first UL or OL it finds.