Remove redundant error logging in from_pretrained() method
Author: lewtun
Pull request: yes

# 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!

Comments:
_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 😃