Ability to log a file, not neccesarily tied to a 'step'

Nobody has claimed this yet.

## 🚀 Feature

Currently there is to my knowledge no other logger-agnostic way to log one-time data than to use `logger.log_hyperparams`, which will for the tensorboard logger store the data in the `hparams.yaml` file.
What i want is the ability to write/log other non-model-hparam files, perhaps with a new method in the form of `logger.log_file(fname: str, data: bytes | str)`.

### Motivation

The ability to store non-hparam data, such as the hardware configuration or the package versions present in the virtual environment, may prove instrumental in debugging failed jobs and to ensure reproducability. Such relevant information may include:

* Current working directory
* Fully qualified hostname (possibly for all ranks)
* Date
* The output of the commands `ifconfig`, `env`, `pip freeze`, `conda list`, `poetry show -t`
* List of cpus, gpus, and ram made available to the process.
* The current git HEAD hash, along the output of `git diff --patch`
* A traceback, should the training fail

My only current option is to either use a non-logger-agnostic way to store these files, or to smuggle this information inside `hparams.yaml`. The former quickly becomes difficult when dealing with remote filesystems, while the latter has has clear UX issues.

### Tangent

Going for the latter solution, I've made the tensorboard logger prefer dumping multiline strings when possible:

```python
def str_presenter(dumper, data):
if len(data.splitlines()) > 1: # check for multiline string
return dumper.represent_scalar('tag:yaml.org,2002:str', data, style='|')
return dumper.represent_scalar('tag:yaml.org,2002:str', data)
yaml.add_representer(str, str_presenter)
```

### Pitch

* Add a `logger.log_file(fname: str, data: bytes | str)` method, which allows you to store any artifact.
* Possibly add a callback which automatically gathers and logs all the data listed in the examples above.

cc @awaelchli @edward-io @borda @ananthsub @rohitgr7 @kamil-kaczmarek @Raalsky @Blaizzy

Start by examining the existing logger.log_hyperparams entry point and the TensorBoard logger behavior described in the issue. Compare how logger backends handle one-time data and determine the scope of a logger-agnostic file API for bytes and strings. Done means non-hparam files can be stored consistently without relying on hparams.yaml.

Written by the indexing model from the issue text.