STCOM-387 Proof of concept: Eject from Settings smart component

[cherewaty]

Purpose

https://issues.folio.org/browse/STCOM-387

The <Settings> smart component contains routing glue, which is at odds with the routing-based architecture strategy outlined in https://issues.folio.org/browse/STRIPES-589.

Approach

We have all the UI we need from stripes-components to be able to construct this functionality with the <Settings> smart component, in a way that ui-users is in complete control of its settings routing.

This PR does not rearrange ui-users's src/settings file organization to clearly delineate route/container components from purely presentational view components. That should be a future scope of work.

I created a stripesConnect() function that makes it easier for route/container components to do their own connection to the data layer, instead of a parent component needing to do it for them.

Breaking change

The <Settings> smart component attempts to programmatically alphabetize the items in each <NavListSection> - this PR does not maintain that functionality.

Blocking issue

The permission sets UI uses <EntryManager>, which also defines routes. With this PR, the permission set routes don't work, since they're nested (and don't use the nested route fork presented here). We'll need to figure out an alternate strategy for ui-users to be able to own those route definitions instead: https://issues.folio.org/browse/STSMACOM-161

[cherewaty]

Closing, since this was really just opened as a proof-of-concept. The eventual owner of this task: feel free to copy this branch and use it as a base to jump off from.