Add permission-guards for organization settings pages

Added necessary subpermissions to setting-page permissions. https://github.com/folio-org/ui-organization/commit/c4c51e8038e2323c58ff63e5c37c2e300a53fba7

(That comment says it's part of UICIRC-10, which is obviously nonsense, but it's too late to change it now.)

Thanks, Wayne! You've been a trooper on this.

Permissions added to folio-ansible (https://github.com/folio-org/folio-ansible/commit/bfb5a8e57545adff9e7728aa5ca82ccde15cbf8d), will be included in next build.

On Slack, suggested:

what if mod-configuration can only be touched from an Okapi module, and Stripes need to communicate with that module directly. Like if mod-users need to store a configuration then it exposes a /users/configuration/foo endpoint, enforce business rules, and store it in mod-configuration.

This is a very interesting idea at all. It's a bit like Wayne's notion of shim modules, but much more lightweight. One could even imagine RMB facilities that make specifying these API endpoints and their associated permissions a matter of a single line of configuration.

Well, I went ahead and created permissions for the four settings pages, so we can use them if we want them and need not if we don't want to. , would you please add the following permissions to diku_admin? ui-organization.settings.key-bindings, ui-organization.settings.locale, ui-organization.settings.plugins, ui-organization.settings.sso.