[Discuss] Installing package assets that require elevated privileges

### Background

In https://github.com/elastic/kibana/issues/111755 we started using the internal `kibana_system` user to install integration package assets into Elasticsearch in order to support automatic upgrades of packages without end user intervention. We then leveraged this capability to remove the requirement for end users to have the superuser role to install packages in https://github.com/elastic/kibana/issues/108252 in 8.1.

One downside of this approach is that it requires that `kibana_system` have the required privileges to install any package assets. This poses a problem for some asset types that require more expansive privileges in Elasticsearch to create:
- transforms [requires these privileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/transform-setup.html#transform-es-security-privileges):
- `transform_admin` built-in role or `manage_transform` cluster privileges,
- `read` and `view_index_metadata` index privileges on source indices, and
- `create_index`, `index`, `manage`, and `read` index privileges on destination indices
- See https://github.com/elastic/kibana/issues/137278 for more in-depth discussion on transforms
- ILM policies [requires these privileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-put-lifecycle.html#ilm-put-lifecycle-prereqs):
- `manage_ilm` cluster privilege to use this API. You must also have the `manage` index privilege on all indices being managed by policy. ILM performs operations as the user who last updated the policy. ILM only has the [roles](https://www.elastic.co/guide/en/elasticsearch/reference/current/defining-roles.html) assigned to the user at the time of the last policy update.
- _supported in the spec, but currently only used by APM_
- Related ES issue: https://github.com/elastic/elasticsearch/issues/72856
- enrich policies [requires these privileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/execute-enrich-policy-api.html#execute-enrich-policy-api-prereqs):
- `read` index privileges for any indices used
- The `enrich_user` [built-in role](https://www.elastic.co/guide/en/elasticsearch/reference/current/built-in-roles.html)
- _not yet supported, but proposed in #292_

To workaround this, we've been making direct edits to the `kibana_system` role definition in Elasticsearch when we need to update a transform or ILM policy. Thus far, this has been acceptable because these asset types are only being used by internal packages that ship with the Stack. However, long-term this is not sustainable and prevents external integration developers from using these features.

### Discussion

- For other packages that would like to use these features, how can we best surface these privilege requirements to the end user? Should Fleet UI be able to automatically detect the privilege requirements to install a given package or should these be defined in the package manifest?
- If we require elevated privileges to install packages containing these assets, will there be any issues with using a mix of users (kibana_system and end user) to install different asset types?
- How could we allow packages to be installed without requiring direct access to these features? Could Elasticsearch support an `install_package` privilege that would grant limited access to these features? For example, could this privilege allow a user to install and remove these asset types from verified packages without granting edit access or the ability to install arbitrary assets?