fix the `tokenizer_config.json` file for the slow tokenizer when a fast version is available
# What does this PR do?

Following the diagnosis discussed and validated in the issue #15283, this PR proposes to modify `PreTrainedTokenizerBase` so that the `tokenizer_file` is no longer retrieved if the calling tokenizer class is of a slow type.

This PR also contains different changes:
- remove the key `"tokenizer_file"` from the global variables such as `VOCAB_FILES_NAMES` when it is a slow version or add it to the fast version when it was missing
- remove the `tokenizer_file` argument from the init of some tokenizer slow
- adapt the `test_tokenizer_mismatch_warning` test because now when someone tries to load files with the wrong tokenizer an error can be returned before the warning is run
- add a new test 


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/master/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/master/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Would love to have your feedbacks @LysandreJik and @sgugger 

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- albert, bert, xlm: @LysandreJik
- blenderbot, bart, marian, pegasus, encoderdecoder,  t5: @patrickvonplaten, @patil-suraj
- longformer, reformer, transfoxl, xlnet: @patrickvonplaten
- fsmt: @stas00
- funnel: @sgugger
- gpt2: @patrickvonplaten, @LysandreJik
- rag: @patrickvonplaten, @lhoestq
- tensorflow: @LysandreJik

Library:

- benchmarks: @patrickvonplaten
- deepspeed: @stas00
- ray/raytune: @richardliaw, @amogkam
- text generation: @patrickvonplaten
- tokenizers: @n1t0, @LysandreJik
- trainer: @sgugger
- pipelines: @LysandreJik

Documentation: @sgugger

HF projects:

- datasets: [different repo](https://github.com/huggingface/datasets)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Examples:

- maintained examples (not research project or legacy): @sgugger, @patil-suraj
- research_projects/bert-loses-patience: @JetRunner
- research_projects/distillation: @VictorSanh

 -->

_The documentation is not available anymore as the PR was closed or merged._<|||||>Thank you so much for your review @sgugger !

Could you tell me more about why "I'm not entirely sure we should remove the filed from the global variables XXX_VOCAB_FILES_MAP as it would be breaking", I'm afraid I'm missing something. (Note, I'm only proposing to remove it from the global variables of the slow version of DPR - which also has a fast version - and from one of the possible slow tokenizer template)

About the signature of the slow tokenizer, this change was most about standardizing the code between the different slow tokenizer classes. This change concerns:
- `mbart`  if we leave `tokenizer_file` in the signature of mbart, potentially if this argument is given at the time of the initialization of the object, the info could be saved in the `tokenizer_config.json` (and result in the same problem as the one points out in the issue).
- `herbert`: it's only for standartization. Here as the argument isn't passed to the` __init__` of the super class (`PreTrainedTokenizer`) it can't be saved in the `tokenizer_config.json`.
- all the other slow tokenizers don't have `tokenizer_file` in their signature<|||||>You are removing content from a public constant, that is a breaking change. Same for changing the signature of tokenizers. I understand that for the second part, it could lead to bugs, so ok to break if it fixes something, but for the first change that is purely cosmetic, maybe we should avoid breaking?

cc @LysandreJik let us know what you think.<|||||>I understand your point! I still have a little trouble knowing where to draw the line between a bugfix and a breaking change.<|||||>Agreed with @sgugger, but otherwise this looks like a very welcome change.<|||||>@sgugger, @LysandreJik , as adviced I have reverted my changes concerning global variables in slow files and changing signatures of the 2 slow tokeniers. :slightly_smiling_face: 