EncoderDecoderConfigs should not create new objects
Author: cronoik
Pull request: yes

# What does this PR do?

1. Removes the creation of separate config objects (pre PR 3:encoderdecoderConfig, encoderConfig, decoderConfig) and uses the existing ones (encoderConfig and decoderConfig now part of the encoderdecoderConfig) 
2. Overwrite `resize_token_embeddings` from the parent class because it is not working for the EncoderDecoderModel and currently throws an error

Fixes #11285


## 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?
- [ ] 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.
- [X] 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).
- [ ] 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. Feel free to tag
members/contributors who may be interested in your PR.

@patrickvonplaten @patil-suraj 

Comments:
@patrickvonplaten @patil-suraj : Could please help me with the failed test? The error message is not that expressive:

> Run cat reports/tests_templates_failures_short.txt
>   cat reports/tests_templates_failures_short.txt
>   shell: /usr/bin/bash -e {0}
>   env:
>     pythonLocation: /opt/hostedtoolcache/Python/3.6.13/x64
> cat: reports/tests_templates_failures_short.txt: No such file or directory
> Error: Process completed with exit code 1.

> Instead of modifying the config, I think one alternate solution is to assign the shared config object to the encoder and decoder, after this line
> 
> https://github.com/huggingface/transformers/blob/95dab34d5588fb155dfed8293ac2fbb1217a95a7/src/transformers/models/encoder_decoder/modeling_encoder_decoder.py#L345
> 
> ```python
> encoder.config = config.encoder
> decoder.config = config.decoder
> ```
Please correct me if I am wrong but what happens, in that case, is the following:
1. Casting already existing config objects to dictionaries.
2. Recreating config objects from those dictionaries.
3. Initializing EncoderDecoderConfig with those new config objects.
4. Throwing away the newly generating config objects by assigning the ones that were already present before step 1.

I think this PR is a cleaner implementation by avoids steps 1-3 and executing 4 directly.



Good point!

But this breaks backward compatibility. With this change, none of the previously trained models will be able to load because the config will now be in-compatible. For ex if you try
```python
config = EncoderDecoderConfig.from_pretrained("google/bert2bert_L-24_wmt_de_en")
```
on this PR, it raises an exception. So loading model fails.

In any case, backward compatibility is of utmost importance.

Hi @patil-suraj 
I have pushed a new version that is now backward compatible and also covers a case I have previously overlooked. After checking the implementation of the parent classes `PreTrainedModel` and `PretrainedConfig` I came to the conclusion that your suggestion is the best because they all transfer dictionaries as parameters and not config objects. 
We could of course implement a type check like;
```
if type(encoder) == dict:
#.....
```
but I think this makes the code less readable. Would be great if you could have a look again and thanks for the constructive review so far :+1:.

Thanks a lot for taking care of this @cronoik :-) It's a nice fix. It would be awesome if you could check out the suggestions and then we can merge this IMO.

Hi @patil-suraj @patrickvonplaten, 
thanks for all the suggestions. I think I am done. Could you please have a look?