[Change Proposal] Support lighter validation mode for settings in internal user-defined packages

Add an additional validation flag to `validation.yml` that allows to circumvent some of the spec validations that prevent the distribution of user-specific configurations.

There are users that create their own custom packages for internal usage, that they install using custom package registries or the upload API. They would like to distribute index configurations this way, so they don't need to separately distribute the package itself and the configuration.

For instance in https://github.com/elastic/package-spec/pull/911 it was proposed to allow to configure the `refresh_interval`, something we are explicitly blocking because we consider it quite dependent on the stack deployment.

Tasks, in this order:

- [ ] Add a new boolean flag to `validation.yml`, such as `allow_settings`, that defaults to false, and initially does nothing.
- [ ] Block publication of packages in the public package registry with `allow_settings: true`.
- [ ] Modify the package spec and/or elastic-package so they allow any setting under `elasticsearch_index_template.settings` when `allow_settings` is set to `true`.

This mode could allow the definition of other settings in the future, we start with `elasticsearch_index_template.settings`.

As an alternative we could add a new error code that can be excluded, but I think that it is better to make this orthogonal to error codes, so we could still add error codes to checks in settings that can be used also when `allow_settings` is not set to `true`, and we can add additional sets of settings to allow with `allow_settings: true`.