This is potentially dangerous if Kibana can update privileges at will. How often do we envision this having to happen?

A discussion happened with regard to this PR in the #kibana-security Slack channel, and I've attempted to summarize and expound upon it here.

The ability to PUT privileges on start-up isn't our main concern at this point, as these are only used by the Kibana application for asserting it's own access-control.

The primary concern at this point is the ability for the Kibana system role to update arbitrary roles.

Kibana is currently creating roles on start-up for the equivalent of the "kibana_user" and "kibana_dashboard_only_user" when the xpack.security.rbac.enabled: true setting is set in the kibana.yml and the roles don't exist in Elasticsearch already. We are currently doing so for a few reasons:

1. We only need these roles when xpack.security.rbac.enabled: true in the kibana.yml and we didn't want to be using reserved roles for these as this could potentially clutter up the list of roles when they weren't being utilized.
2. When we do use a reserved role for the "kibana_user" this can't be modified, so the user isn't able to modify anything on the role, including the Kibana privileges which will commonly be modified as soon as Spaces is a reality
3. We've historically only created "kibana_user" and "kibana_dashboard_only_user" roles for the default Kibana "tenant" and made the user manually create these roles for the other "tenant", creating these automatically on startup was supposed to ease this process. This one I'm less concerned with, as hopefully multi-tenant deployments just stop happening as soon as Spaces is released.

These are the existing solutions that I've thought of, or @joshbressers proposed in the #kibana-security Slack channel.

1. Require a user with the manage_security cluster privilege login to Kibana first to create the roles.
2. Utilize a reserved role for the new "kibana_user" and "kibana_dashboard_only_user" roles
3. Allow the Kibana server to only create new roles, not update existing roles

Pinging @elastic/es-security

After some discussion, we've removed the need for the Kibana system role needing to GET/PUT roles, so this only adds the ability to for the Kibana system role to GET/PUT privileges.