[Seq2Seq] Allow EncoderDecoderModels to be trained with Seq2Seq
# What does this PR do?

This PR changes the Seq2Seq Trainer a bit to:
1) Make it work with `EncoderDecoder`
2) Align its API more with the general `Trainer`

@sshleifer @patil-suraj @sgugger - it would be great if you could take a look and give your general opinion on it :-) 
If this would be ok for you, I will fix the examples test.
LGTM, thanks for aligning it! We just need some way to pass `eval_beams` and `max_gen_length`.

>We can have a `Seq2SeqTrainingArguments` that subclasses `TrainingArguments` if that helps.

@sgugger  we do have `Seq2SeqTrainingArguments` class
https://github.com/huggingface/transformers/blob/d99ed7ad618037ae878f0758157ed0764bd7f935/examples/seq2seq/finetune_trainer.py#L37<|||||>> @sgugger we do have `Seq2SeqTrainingArguments` class

Ah, had forgotten about that :-)<|||||>`eval_beams`/`eval_max_gen_length` reasoning:
@patil-suraj said exactly this LOL, but in my words:
users are not good at modifying configs locally. We want to have a way to run `num_beams=2` during the generation step, but then end up with a trained model with the default # beams. In general, we try not to manipulate config attributes that would only be desired during training.
<|||||>Also would <3 an encoder decoder test in `examples/seq2seq/test_finetune_trainer.py`. 
<|||||>After discussion @sshleifer - changed the `Seq2SeqTrainer` to be fully backwards compatible and to work with EncoderDecoder.
@sshleifer - cannot add EncDec test yet because the complete command line setup is too constrained (requires `prepare_seq2seq_batch` to be defined for all tokenizers, etc...) => will see how to add this in the future. 

@sshleifer , @patil-suraj - could you do another review please? :-) <|||||>Should be good - I don't really see how -100 would slow down the TPU, but let's wait for @LysandreJik opinion here. <|||||>Can't seem to reply to the comment, but yes, the line @sshleifer is pointing at will slow down on TPU since it's probably using a `torch.where` behind the scene which does not have an XLA operation AFAIK.<|||||>> Can't seem to reply to the comment, but yes, the line @sshleifer is pointing at will slow down on TPU since it's probably using a `torch.where` behind the scene which does not have an XLA operation AFAIK.

Okey, I see -> let's move back in the old CE loss function then to keep backward compatibility! 

@sshleifer - one last review please :-) 