[RFC] Deprecate `log_every_n_steps` from Trainer

Nobody has claimed this yet.

## Proposed refactoring or deprecation

Deprecate `log_every_n_steps` from Trainer and make it available as a parameter to loggers that have this capability.

### Motivation

Same reasons as #8991. How often to log should be considered an internal implementation detail of each logger

### Pitch

Deprecate `log_every_n_steps` from Trainer, and move it to the init for logger classes that support this functionality (e.g. CSVLogger).

______________________________________________________________________

#### If you enjoy Lightning, check out our other projects! ⚡

- [**Metrics**](https://github.com/PyTorchLightning/metrics): Machine learning metrics for distributed, scalable PyTorch applications.

- [**Flash**](https://github.com/PyTorchLightning/lightning-flash): The fastest way to get a Lightning baseline! A collection of tasks for fast prototyping, baselining, finetuning and solving problems with deep learning

- [**Bolts**](https://github.com/PyTorchLightning/lightning-bolts): Pretrained SOTA Deep Learning models, callbacks and more for research and production with PyTorch Lightning and PyTorch

- [**Lightning Transformers**](https://github.com/PyTorchLightning/lightning-transformers): Flexible interface for high performance research using SOTA Transformers leveraging Pytorch Lightning, Transformers, and Hydra.

cc @tchaton @justusschock @awaelchli @borda @carmocca @edward-io @ananthsub @rohitgr7 @kamil-kaczmarek @Raalsky @Blaizzy @kaushikb11 @akihironitta

Start by reviewing the Trainer's log_every_n_steps parameter and logger classes that support logging frequency, including CSVLogger. Determine which loggers need the parameter, then deprecate it on Trainer and expose it through the applicable logger initializers, with tests confirming the updated configuration.

Written by the indexing model from the issue text.