[ML] Prefer secondary credentials when storing security headers for background tasks

[droberts195]

When a datafeed or data frame analytics job is created or updated ML and security is enabled will store the security headers from the request so that the datafeed or data frame analysis that later runs as a persistent task can access the source data using the privileges of the user who created or updated it.

#52093 added the option for a request to contain a secondary set of credentials. In cases where a secondary set of credentials is supplied, the security headers that get stored with the datafeed or data frame analytics config should come from the secondary credentials rather than the primary credentials. This needs to be clearly documented for all four endpoints.

In cases where only one set of credentials is supplied the headers from these should still be stored, exactly as at present.

This change should target 7.8.

We will need to find a way to convert the secondary credentials added in #52093 into the format used for the synthesized _xpack_security_authentication header so that they can be seamlessly stored in the config identically to how primary credentials are stored. Some consultancy from the ES security team may be required for this.

(The reason for adding this feature is to support the "ML in Spaces" UI project. Eventually whether ML can be used in the UI will be controlled by Kibana privileges instead of Elasticsearch privileges, with the Kibana system user calling ML Elasticsearch endpoints after first authorising against ML Kibana privileges. However, for access to the source data we will still need to know the logged-in Kibana user and it should be their credentials that are used to obtain the source data when the datafeed or data frame analytics job is started.)

[elasticmachine]

Pinging @elastic/ml-core (:ml)