### Summary

We're often asked how to include arbitrary control-side contextual metadata with task invocations, and to include that metadata in target-side task log messages. e.g.: sending an AWX/Controller Job ID to the target hosts on each module invocation that occurred from that job, and logging it in the module-generated syslog/Windows Application Event Log entries for future correlation with the owning job.

I've not seen any consensus on precisely *which* data to include; one person's "critical forensic correlation data" is another's "unacceptable disclosure of sensitive execution detail". Seems like we'd need a generic facility to specify environment vars and/or hostvars to sample on the control host to be included with task invocations (under a reserved dictionary arg), and adjust the module logging APIs to include them.

My initial thought is to define a new core config element (defaulting to none) that allows the user to define a templated expression that would be rendered as part of each task's templating under a host context. The rendered result would be sent to modules as a new reserved internal module var. The module logging APIs would then include this value verbatim, when present. Other module code would also have access to the value, which could be used for anything. The new config would be settable either via ansible.cfg or an envvar, making it easier for AWX/Controller to later provide a mechanism to configure it for jobs using core versions that support it, while older versions would just silently ignore it. 

Maybe something like:

```
ANSIBLE_ADDITIONAL_TASK_CONTEXT='{{awx_job_id}}'
```

When this config is non-empty, the defined template would be rendered for each task/host invocation, and its result included in a new `_ansible_additional_task_context` reserved module var. The resulting value, as with any Ansible template expression, could be of arbitrary complexity (eg, returning a data structure instead of just a scalar).  The module logging APIs would include the serialized value verbatim in log messages when it is present, eg "ansible_additional_task_context=(whatever the value was)".


### Issue Type

Feature Idea

### Component Name

module invocation and logging

### Additional Information

<!--- Paste example playbooks or commands between quotes below -->
```yaml (paste below)

```


### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct
argument_spec,
            mutually_exclusive=mutually_exclusive,
            required_together=required_together,
            required_one_of=required_one_of,
            required_if=required_if,
            required_by=required_by,
        )
        validation_result = validator.validate(new_module_args)
        new_module_args.update(validation_result.validated_parameters)
        try:
            error = validation_result.errors[0]
        except IndexError:
            error = None
        
        if error:
            msg = validation_result.errors.msg
            if isinstance(error, UnsupportedError):
                msg = f"Unsupported parameters for ({self._load_name}) module: {msg}"
            raise AnsibleActionFail(msg)
        return validation_result, new_module_args
    def cleanup(self, force=False):
        """Method to perform a clean up at the end of an action plugin execution
        By default this is designed to clean up the shell tmpdir, and is toggled based on whether
        async is in use
        Action plugins may override this if they deem necessary, but should still call this method
        via super
        """
        if force or not self._task.async_val:
            self._remove_tmp_path(self._connection._shell.tmpdir)
    def get_plugin_option(self, plugin, option, default=None):