Updates to `ViewManager` "pinning"

[amcclain]

ViewManager includes a feature that allows users to selectively "pin" views to their drop-down menu. Admins managing globally shared views can also choose to "pin by default", meaning a global view will appear in all users' menus unless they explicitly unpin.

This feature can be overkill for some use cases. We would like the ability to disable it entirely, meaning:

• All views always pinned / visible in menu. Global views always visible in everyone's menu.
• No mention of pinning in management dialog, for single or shared views.
• We would then need to deal with possible shared views from many individual users - we would not want everyone's menus to start showing top-level items for each user that has published a shared view. (That's the current behavior when you find another user's view and pin it.)
  • Suggest inserting a top-level menu item "Other Users Views >" that expands to list of users, which then each expand to show their view.
  • This seems like it would scale reasonably w/o requiring pinning.
  • Expectation is that pinning disabled in simple use cases, where user sharing might well be disabled also, or only a small handful of users exist, so this solution just needs to be "good enough" to support edge case.

The terminology "pinning" is not super clear, and can conflict with other usages of the word in an app. In the worst case, we have a conflict with a client app that has a custom quick-picker bar of saved views shown in a dedicated component alongside the VM button. Users "pin" views via a custom control to get them to show up in that custom switcher, but now the usage of the word in the Hoist mgmt dialog is confusing.

• Minimal change would be to clarify the language a bit in our dialog - really just for the global views, where we have a switch labelled "Pin by default". This could be "Pin to all user menus by default" just to get the clarity that it affects the menu and to better match the text on the button users have to pin/unpin views themselves.
• If we expect other implementations like the client app mentioned above, where views could be shown in a custom location, we could generalize the pin:boolean to something more like pinTo:string[], where the strings are arbitrary tokens with "menu" (or "xhMenu") reserved for Hoist.
• Devs could pass in supportedPinLocations to enable users to choose alternate places for views to go, and that metadata would be saved with the user's view state, where it could be read by a custom component to determine if they should show a view or not.
  • Would likely need to be {value:string, label:string}[]
• We could then use isEmpty(supportedPinLocations) to disable pinning entirely.
• If supportedPinLocations has multiple values, we would replace switch input with multi-select.
• We would remove the pin column from the grid within the mgr dialog - it does not seem necessary.

[amcclain]

See some smaller pinning-related asks in #3986

[amcclain]

After some more time spent using and supporting this feature in production settings, I would like to propose the following change:

• Eliminate optionality around "pin by default" for global views - remove the setting entirely. Global views are always pinned to user menus unless explicitly unpinned by the user.

[lbwexler]

All for it. Was unnecessary -- if a view is good enough to be global, its good enough to be pinned by default.