Update Special Language Tokens for PLBART
# What does this PR do?

This PR fixes the special tokens for PLBartTokenizer, raised in Issue #19505. Previously the tokenizer treats java, python etc. as special tokens, and removes them when decoding is performed.

@LysandreJik
_The documentation is not available anymore as the PR was closed or merged._<|||||>cc @ArthurZucker <|||||>Hey! Great work 👍 
We should make sure the CI tests are all green, and could you add a new test like `test_special_code_tokenization` where we make sure that the expected behavior of #19505 works<|||||>@ArthurZucker ok, tests are green. I added to the `test_full_multi_tokenizer,` `test_full_base_tokenizer` tests to check for this behaviour as the test tokenizer is already loaded in these tests. <|||||>@ArthurZucker bumping this. <|||||>The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_19980). All of your documentation changes will be reflected on that endpoint.<|||||>The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_19980). All of your documentation changes will be reflected on that endpoint.<|||||>The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_19980). All of your documentation changes will be reflected on that endpoint.<|||||>Thanks, @ArthurZucker! I made some changes to the tests with intermediate inputs and accepted several changes. 

> calling `_convert_lang_code_special_format` in the `src_lang.setter` to avoid calling it everywhere / avoid one liner functions

With this, wouldn't the `src_lang would.setter` have to be called everywhere instead? 
I think its quite difficult to make it backward compat and simpler as you suggest, as there are lots of places the user provides the src_lang, tgt_lang and there is also `self._src_lang` as well as` self.src_lang`. This at least preserves the functionality as before and the mapping as under-the-hood.<|||||>@ArthurZucker made that readability change. can we merge?