adapt mbart and generate for Mbart50
# What does this PR do?
This PR adapts `MBartForConditionalGeneration` and `generate` for mbart-50 models. 

There are two main differences between mbart-50 and existing mbart-cc25 models 
1. for mbart-50 both source and target language text begin with the `<language token>`,  in mbart-cc25 `<language_token>` is used as suffix token.
2. Also the `decoder_input_ids` begin with `[eos] [tgt_lang_token] ...`, so for generation we need to use `eos` as the `decoder_start_token_id` and force the `tgt_lang_token` as the first generated token.

This PR 
1. adds `MBart50Tokenizer` which encodes the text as described above, IMO adding a new tokenizer makes sense as it'll make it explicit that mbart-50 encodes the text differently.
2.  introduces two new `generate` arguments  and `LogitsProcessor`
    - `forced_bos_token_id` and `forced_eos_token_id`,  to force a specific start and end token. This is particularly useful for 
       many to many and one to many translation models, so we can pass different language tokens as `forced_bos_token_id` to 
       `generate`, 
    - `ForcedBosTokenLogitsProcessor` and `ForcedEosTokenLogitsProcessor`
3. Remove `adjust_logits_during_generation` method from all models (except from `Marian`) and handle that use case using the newly introduced logits processors.
4. remove the `force_bos_token_to_be_generated` argument from `BartConfig`

For `Marian` we still need to keep the `adjust_logits_during_generation` method to force the model to not generate pad token. Adding the pad token to `bad_words_ids` does not resolve this issue, the score of `pad_token_id` needs to be set to `-inf` before calling `log_softmax`.

Below is an example of mbart-50 model using `forced_bos_token_id`

```python
from transformers import MBartForConditionalGeneration, MBart50Tokenizer

article_hi = "संयुक्त राष्ट्र के प्रमुख का कहना है कि सीरिया में कोई सैन्य समाधान नहीं है"
article_ar = "الأمين العام للأمم المتحدة يقول إنه لا يوجد حل عسكري في سوريا."

model = MBartForConditionalGeneration.from_pretrained("facebook/mbart-50-large-many-to-many")
tokenizer = MBart50Tokenizer.from_pretrained("facebook/mbart-50-large-many-to-many")

# translate Hindi to French
encoded_hi = tokenizer.prepare_seq2seq_batch(src_texts=article_hi, src_lang="hi_IN", return_tensors="pt")
generated_tokens = model.generate(**encoded_hi, forced_bos_token_id=tokenizer.lang_code_to_id["fr_XX"])
tokenizer.batch_decode(generated_tokens, skip_special_tokens=True)
# => "Le chef de l 'ONU affirme qu 'il n 'y a pas de solution militaire dans la Syrie."

# translate Arabic to English
encoded_ar = tokenizer.prepare_seq2seq_batch(src_texts=article_ar, src_lang="ar_AR", return_tensors="pt")
generated_tokens = model.generate(**encoded_ar, forced_bos_token_id=tokenizer.lang_code_to_id["en_XX"])
tokenizer.batch_decode(generated_tokens, skip_special_tokens=True)
# => "The Secretary-General of the United Nations says there is no military solution in Syria."
```

TODOs:
- [x] Make sure all generation related slow integration tests pass for affected models 
  - [x] BART
  - [x] mBART (one test is failing, but it's failing on master as well, so not related to this PR)
  - [x] Blender
  - [x] FSMT
  - [x] Marian
  - [x] Pegasus
  - [x] Generation integration test
- [x] add tests for `ForcedBosTokenLogitsProcessor` and `ForcedEosTokenLogitsProcessor`
- [x] document mBART-50
- [x] Add model cards ([all mbart-50 models](https://huggingface.co/models?filter=mbart-50))
- [x] add the forced params to `facebook/bart-large-cnn`'s config on the hub
- [ ] notebook explaining  how to use the one-to-many and many-to-many translation models

Fixes #7060
I like the idea of using `LogitsProcessor`, my only concern is now each time the user wants to use a different `max_length` they would need to pass the `forced_pos_id_pairs= {max_length: eos_token_id}`.

Also IMO `prefix_token` sounds more intuitive than `forced_pos_id_pairs`. So I think we could add `ForceTokenProcessor ` and keep both `prefix_token` and `forced_pos_id_pairs` arguments. 

And if `prefix_token` is passed or `config.force_bos_token_to_be_generated` is `True` we set
```python
forced_pos_id_pairs = {2: prefix_token or bos_token_id, max_length: eos_token_id}
```

this would avoid breaking change.
<|||||>Putting our discussion with @patil-suraj down here for everyone to see. @patil-suraj brought up a good point that `forced_pos_id_pairs` is not super user friendly and might be hard to read and people usually never force "in the middle" tokens to be generated. So I like the proposed approach making two LogitsProcessor better as well => we should therefore make 
a `ForcedBosTokenLogitsProcessor` that takes a `token` as input and always forces the first token to be generated and a `ForcedEosTokenLogitsProcessor` that also takes a `token` as input and forces this token to be generated at `max_length`. 
As discussed we should delete all `adjust_logits` functionality and also get rid of Bart's `config.force_eos_to_be_generated` parameter while keeping full backwards compatibility as discussed.<|||||>Thanks a lot for making this work @patil-suraj! 

Will review the PR now. I saw that you changed the config for `facebook/bart-large-cnn` online which is nice, but should not delete: `force_bos_token_to_be_generated` from the config or it won't be backwards compatible (previous transformer versions need to still use this param). Also it seems like you accidently uploaded a `.ipynb_checkpoints` folder: force_bos_token_to_be_generated<|||||>> We have to make sure that all slow tests for Bart, MBart, Pegasus, Marian, Blenderbot, BlenderbotSmall, FSMT, RAG pass for both PT and TF. I think some of the RAGTokenGeneration could have been broken here

all slow tests are passing for PT, will run the RAG tests now. Also, there is no `force_bos_token_id_to_be_generated` parameter in `RagConfig`, it's in the `generator` config if the `generator` is BART, and `BartConfig` already handles this.

> Not sure whether we want to do inheritance for the MBart50Tokenizer

No strong opinion here will remove the inheritance.

Regarding the `prepare_seq2seq_batch` method:
These checkpoints are mostly intended for multilingual fine-tuning/translation,  in this case, it's actually nice to be able to pass lang_id directly for encoding rather than setting `src_lang` and `tgt_lang` on tokenizer each time we have a new language pair.

If we have fixed src and target language then in that case `prepare_seq2seq_batch` definitely doesn't make much sense.