Refactor `prepare_seq2seq_batch`
Author: sgugger
Pull request: yes

# What does this PR do?

This PR refactors the logic of `prepare_seq2seq_batch` which is roughly:

1. tokenize inputs
2. make some changes to prepare the tokenizer for target encoding
3. tokenize targets
4. revert the changes made in 2 for the next tokenization

by introducing a new context manage that is in charge of 2 and 4 (the method is then the same for all tokenizers, with some small exceptions).

The end plan is to use this new context manage in the examples and deprecate `prepare_seq2seq_batch` before removing it in a next major version: it's as if we had a `prepare_text_classification_batch`, `prepare_token_classification_batch`... and so on for each task and also doesn't allow for the preprocessing to be done once and for all (since it's used to tokenize text on the fly right now).

This for future development, the PR in itself is 100%-backward compatible.

Comments:
Could you run the slow tests of the models concerned?

For reference, some discussions on why the method was added in the first place:
https://github.com/huggingface/transformers/issues/6080
https://github.com/huggingface/transformers/pull/6103

In general, I agree very much with your approach here and I like the idea of a context manager. From a user perspective for Seq2Seq models these are the common practices IMO:

**Inference in 99% of the time**: You use generate() in 99% of the time so you tokenize only your input_ids exactly the same way you'd do it for other models (like gpt2)
     
**Inference in 1% of the time**: In case you just want to do a single forward pass, you will have to input `input_ids` and `decoder_input_ids` -> this is usually only for special cases so one can reasonably expect the user to know how the model works. However in this case we either do need the context-manager or a `prepare_seq2seq_batch` method since the start token for the decoder is very much different from the one of the encoder. This is actually such as special case that we don't even need any magic functions for that, but just assume that the user manually prepends the `decoder_start_token_id` to `decoder_input_ids`.

**training**: All seq2seq models usually only require the `labels` and `input_ids` and then the `decoder_input_ids` are automatically generated, with a method that just shifts the `labels` one to the right and adds the `decoder_start_token_id`. So far there is not a single seq2seq model that does not have this mechanism and thus all seq2seq models can be trained by only passing `input_ids` and `labels`. So I think we can assume that all seq2seq models only require `input_ids` and `labels`. => this makes them then also very similar to how BERT-like models are trained since they also just need `input_ids` and `labels`. Here the `prepare_seq2seq_batch` method is useful because it tokenizes both inputs at once and has some additional features like `src_lang` and `tgt_lang` (useful for MBart and Marian only though) and `target_max_length`, etc....but as said in the issues referenced above and mentioned in this PR as well, I do think that those are some "magic" functionalities that should not have their origin in `src/transformers` but better in `examples` -> so I think we agree here @sgugger .

So only thing, I'm a bit worried about is that some users got very accustomed to the `prepare_seq2seq_batch` method so that they won't be too happy about removing it (especially since it's also doing all the `max_length` and `max_target_length` automatically.

But very much in favor of this change

Failure is independent, due to the new tokenziers release, so merging.