Change how "additional_special_tokens" argument in the ".from_pretrained" method of the tokenizer is taken into account
Author: SaulLu
Pull request: yes

# What does this PR do?

This PR is a proposal for the issue #12533.

## Motivation

This change in behavior is motivated in particular by the [`test_special_tokens_initialization` test in `test_tokenization_common`](https://github.com/huggingface/transformers/blob/v4.9.2/tests/test_tokenization_common.py#L3132). 

This test consists in loading thanks to the method `from_pretrained` a tokenizer (on the hub)  and adding in the arguments `additional_special_tokens=[AddedToken("<special>", lstrip=True)]` then to check that this new special token `"<special>"` was well added.

```python
added_tokens = [AddedToken("<special>", lstrip=True)]
tokenizer_r = self.rust_tokenizer_class.from_pretrained(
                    pretrained_name, additional_special_tokens=added_tokens, **kwargs
r_output = tokenizer_r.encode("Hey this is a <special> token")
special_token_id = tokenizer_r.encode("<special>", add_special_tokens=False)[0]
self.assertTrue(special_token_id in r_output)
```

This test does not currently work in one case: if the repository on the hub contains a `"special_tokens_map.json"` file that defines the value of `"additional_special_tokens"` then the new argument `additional_special_tokens=[AddedToken("<special>", lstrip=True)]` added in the `.from_pretrained` method is ignored.

## New behavior introduce by this PR

This PR introduces a change that gives priority to arguments provided in the `.from_pretrained` method. Understand that if there is a competition between the definition of an argument in the `.from_pretrained` method and in the repository files, then the definition of the argument in the method will be chosen.

## 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. In particular:
@LysandreJik and @sgugger - It would be awesome if you could validate the new behavior and give your opinion on the PR
@NielsRogge - It would be great if you could look at the proposed change in the tokenization of Luke and possibly the test of Canine
@patil-suraj - It would be great if you could look at the proposed change in the tokenization of M2M-100 and MBart50. For these 2 models, I have proposed changes so that the user can still define additional special tokens even if these templates already define additional special tokens corresponding to the language codes. This behavior was already present in `TokenizerMBart` but not in the tokenizers of these last models. If these are not desirable behaviors for these models, I can reverse the changes and just disable the corresponding tests for these models
@patrickvonplaten - it would be great if you could take a look at the change in the Wave2Vec2 processor test (if you agree with this change, there is the same function used in `test_tokenization_wave2vec2.py` that I didn't change)

Thank you for your time

## Failing Test
One test is currently failing `test_run_seq2seq_no_dist` in `test_trainer_ext.py`. At the moment I'm not sure that I see the link with the changes I introduced, but I'm still investigating.

EDIT: I think this test is failing do to a change in [sacrebleu](https://github.com/mjpost/sacrebleu/) which affects :hugs: datasets library. I understand that the problem is in process to be solved on the datasets side ([PR](https://github.com/huggingface/datasets/pull/2778))



Comments:
LGTM! Thank you for making this cleaner.

Feel free to merge after solving the code quality issues!