[ClickAwayListener] Trigger in mouseup instead of click

[eps1lon]

• Closes Snackbars not read by screen reader #29080: https://codesandbox.io/s/snackbar-alert-nvda-issues-forked-te04o?file=/src/App.js
• Closes [ClickAwayListener] Calling onClickAway straightaway when used with Select #25578: https://codesandbox.io/s/vigorous-albattani-8e2xv
• Fixes a tap highlight being applied on iOS to children of ClickAwayListener if the children took up a small amount on the screen: https://codesandbox.io/s/clickaway-material-ios-tap-highlight-3prkw
  For example clicking "Click me" in https://codesandbox.io/s/clickaway-material-ios-tap-highlight-y42nf?file=/demo.js would trigger a tap highlight even though the child is not actually interactive (notice the black transparent flash):

tap-highlight-click-away.mp4

Note that this usually isn't an issue since iOS only applies the tap highlight if the element with an explicit onclick takes up a small portion of the screen (or parent?). As far as I can tell it's <30% (see https://trac.webkit.org/browser/webkit/trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm?rev=286260#L2096. I don't actually know for sure if the linked value is responsible but looking at the code overall I'm fairly certain these are the iOS tap heuristics).

Basically we apply click-away heuristics while processing mouseup instead of click.

Note that this change needs extensive manual testing and has the potential of breaking existing applications that relied on clickaway firing after mouseup events finished bubbling.

Browser run: https://app.circleci.com/pipelines/github/mui-org/material-ui/57385/workflows/d26c82b1-22e6-41c7-87ec-13683dab9b0c

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 243aeca

[siriwatknp]

Note that this change needs extensive manual testing and has the potential of breaking existing applications that relied on clickaway firing after mouseup events finished bubbling.

Would this be considered as breaking change? If yes, should we add it to v6?