Remove redundant error logging in from_pretrained() method
# What does this PR do?

This PR removes the redundant error logging in the `from_pretrained()` method of:

* Configs
* Tokenizers
* Models
* Feature extractors

I also took the liberty of removing the redundant logging from the file utils. If a genuine error is raised, the user will still see it since the corresponding `EnvironmentError` is raised and provides a helpful message. 

## Why do this?

In PRs #15620 and #15625 we observed that the `AutoModel.from_pretrained()` method displays a 404 error in the logs when PyTorch and TensorFlow are installed in the same environment and:

* The `transformers.onnx` package is used to export a pure TensorFlow model
* The `pipeline()` function is used to load a pure TensorFlow model

Examples of specific log messages are shown below:

```bash
# Displays 404 Client Error: Entry Not Found for url: https://huggingface.co/keras-io/transformers-qa/resolve/main/pytorch_model.bin
python -m transformers.onnx --model=keras-io/transformers-qa onnx/
```

```python
from transformers import pipeline

# Displays 404 Client Error: Entry Not Found for url: https://huggingface.co/keras-io/transformers-qa/resolve
p = pipeline("question-answering", model="keras-io/transformers-qa")
```

The reason these logs appear is that both the `transformers.onnx` package and the `pipeline()` function attempt to first load the model weights in an `AutoModel` class (see [here](https://github.com/huggingface/transformers/blob/fcb0f7439754f1b830ebac2070a0c8a8f003f7c5/src/transformers/onnx/features.py#L306) and [here](https://github.com/huggingface/transformers/blob/fcb0f7439754f1b830ebac2070a0c8a8f003f7c5/src/transformers/pipelines/base.py#L305)). If the model repo only has TensorFlow weights, the error is logged, but the API resolves it by using either `from_tf=True` or instantiating a `TFAutoModel`.

These logs are potentially confusing for end-users and it's not clear we need them since we raise `EnvironmentError` for "real" errors and provide a pretty clear message on what went wrong. 

If we have to keep these logs, one alternative is to rewrite the `transformers.onnx` and `pipeline()` logic so that the error isn't raised for these edge cases (both frameworks installed, trying to load a pure TF model). I'd rather not do that, so happy to hear other suggestions!
_The documentation is not available anymore as the PR was closed or merged._<|||||>> If we're removing them, there are plenty others, in the flax and tf modeling file, the config utils, tokenization utils and feature extractor utils.

I just want to make sure that @lewtun is agreeable to that - as sometimes a small improvement can turn into multi-day project - we could also merge this and do another PR for an extended clean up if you don't feel you want to expand the scope. IMHO, of course.<|||||>Checking the history, it was introduced by @julien-c in #8324
Do you remember if there was a specific reason to have both the error log and the error raised Julien? For context, we're dealing with errors logged when they shouldn't be if we do a try catch (try to load a PyTorch model, then if it fails try to load the TF model associated like in the pipeline),<|||||>@sgugger I think it was just the library's logging style at the time of the linked PR. No objection to changing this on my side!<|||||>Hi @stas00 @sgugger thanks for the feedback and historical context! 

I did a search for all `logging.error(err)` instances and removed them - please let me know if there's some other modules I should be looking at as well. If that's it, then I think this PR is ready for another pass 😃 