Scroller: Add click() feature

[nexushoratio]

When working on the focus UX change, we discovered that focusOnElement() is broken by design. When an element that does not generally support focus (e.g., <div>) is used, and tabindex is taken away, focus goes back to document.body. Though, depending on browser, TAB to the next field will work as expected.

A common Shortcut is to somehow select the current item, often using Enter. After much exploring, it would probably work like:

if ([document.body, scroller.item].includes(document.activeElement) {
  handleLocally();
} else {
  document.activeElement.click();
}

In some cases, handleLocally() would be a call to clickElement(), sometimes with matchSelf = True, sometimes not. In one, it is a complicated function that depends on context.

In all cases, if unable to find something to click, postInfoAboutElement() is called.

Not yet clear if should just always be a function (like uidCallback) that returns an element, or a selector list/matchSelf object that would get passed to clickElement(), or support both. Would probably end up being both.

• Bare click() method as initial placeholder
• Enhance Scroller~How with click config property, default null
• Add feature flag and add to all current users of Enter
• In click():
  • if no current item, call document.activeElement.click()
  • config === null, call NH.base.issues.post() about programming error
  • If is a function, takes HTMLElement, returns {?HTMLElement}, if null, call postInfoAboutElement(item)
  • If object, call clickElement() with selectors and matchSelf value, if returns false, call postInfoAboutElement(item)
  • Make clickConfig (ClickConfig|ElementFinder) be consistent with how base/selectors vs containerItems are handled
• Update existing Enter
  • MyNetwork.viewItem
  • Jobs.activateJob (rename viewJob ?)
  • Notifications.activateNotification (rename viewNotification? No, because it may cause a message pop-up)

Issue #232 can be used to decide about utilizing this else where.