This is dependent on #38, as #38 introduced a new focus state that doesn't go away on its own. I figured this could be worth a separate discussion.

These two functions are useful when there are scripted behaviors that alter menu items. This allows those behaviors to interact with <details-menu> easily, instead of getting into the implementation details of <details-menu>.

For example,

A filtering behavior would want to clear focus after filtering. With this change, it will be able to call detailsMenu.clearFocus() instead of

1. duplicating details-menu's logic for querying menu items
2. clearing focus states based on details-menu's implementation

A filtering input would want to trigger an implicit selection for the first filtered result on Enter. With this change, it will be able to invoke detailsMenu.selectFocusOrFirst() instead of

1. check for currently focused menu item or finding first item by duplicating details-menu's logic for querying menu items
2. simulate a click() on the item

Example:

menu.addEvenetListener('menuitem-filtered', () => {
  menu.clearFocus()
})

input.addEvenetListener('keypress', event => {
  if (event.key !== 'Enter') return
  input.closest('details-menu').selectFocusOrFirst()
})

Note: In this use case the current focus check in selectFocusOrFirst is redundant, since the input would have focus. "Focus or first" is mostly an explicit name for an implicit default.