Remove a TF usage warning and rework the documentation
# What does this PR do?

Recently we moved the warning for boolean argument misused in TF models from `warnings.warning(...)` to `tf.Print` to avoid the overhelm of messages in the output. Nevertheless, the usage of `tf.Print` prevent all our TF models to be compiled and executed with XLA and quantized with TFLite because the `Print` operator is not supported in XLA and TFLite.

As a solution for both issues (logging overhelm + XLA compilation/execution) I propose to simply remove the logs and state the use case directly inside the documentation for all the TF models.

Not in favor of this to be honest...Warnings / Print statements are super important IMO. It's weird that `tf.Print` is not supported in XLA -> how are logs / warnings / print statements then produced in XLA?<|||||>XLA/Graph/TFlite execution are not made to have things to be printed, this includes some of the assert usage as well.<|||||>@patrickvonplaten  TF XLA has few other known issues https://www.tensorflow.org/xla/known_issues<|||||>> @patrickvonplaten TF XLA has few other known issues https://www.tensorflow.org/xla/known_issues

Thanks for sharing! I'm still very surprised by your message:

> Nevertheless, the usage of tf.Print prevent all our TF models to be compiled and executed with XLA and quantized with TFLite

To me, this means that every TF Repo that wants to be executable with XLA has no `tf.Print(...)` ops. That's a pretty hard requirement no? <|||||>> To me, this means that every TF Repo that wants to be executable with XLA has no tf.Print(...) ops. That's a pretty hard requirement no?

I agree, it is, but I see very rarely `tf.print(..)` to be used. As far as I know I never seen it implemented in official TF models during runtime (you can easily check with a quick search on https://github.com/tensorflow/models), usually it is used when evaluating a model, which is a use case that is not XLA related.<|||||>Can we use
```
import tensorflow as tf
tf_logger = tf.get_logger()
tf_logger.warn(xxx)
```
intead?<|||||>@sgugger yes, using the internal TF logger should work as expected, but I'm not sure if it will bring any conflict with the actual transformers logger in terms of configuration.

Do you want me to use it instead, and we will see later if there is indeed any conflict?<|||||>Yeah I think it would be best to have a warning the user can't silence with our centralized logging that none.<|||||>Ok done! I restored the warning but with the internal TF logger.