[PretrainedConfig] Fix save pretrained config for edge case 
Author: patrickvonplaten
Pull request: yes

# What does this PR do?

There is an edge case for which the "diff" save method for `PretrainedConfig` fails. We decided a while ago in this PR: https://github.com/huggingface/transformers/pull/3797 that we wanted to have more readable configs and thus tweaked the `save_pretrained()` method so that only parameters that are different to the default **PretrainedConfig** class are serialized. 

There was an edge case we did not consider:

If a parameter, like `add_cross_attention` defaults to `True` in `ProphetNetConfig`, but is by default `False` in `PretrainedConfig` a problem can arise when a user wants to save `add_cross_attention=False` in his `ProphetNetConfig`. Because `add_cross_attention=False` corresponds to the `PretrainedConfig` default case, this parameter will not be serialized and thus when reloading the config, the parameter defaults to `ProphetNetConfig` which is `True` and which is then an error.

This PR fixes this behavior by simply making sure that a parameter is only **not** saved if it is equal to both `PretrainedConfig` and `ProphetNetConfig`. 

This feature requires configs to be instantiated without providing any parameters. This is currently not possible for the `EncoderDecoderModelConfig` and `RagConfig` because those configs are composed of multiple sub-configs which have to be provided. => A new class attribute `is_composition` is added to correctly handle these classes.

Two tests are added.

Also cc @stas00 for FSTM config.

## Before submitting
- [x] 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 the it if that's the case.
- [ ] 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).
- [x] Did you write any new necessary tests?


## Who can review?




Comments:
Any reason not to look at just the config class? At a first glance, I'd say we want to compare the defaults to the class we instantiated, not to the superclass `PretrainedConfig`.

> Any reason not to look at just the config class? At a first glance, I'd say we want to compare the defaults to the class we instantiated, not to the superclass `PretrainedConfig`.

Back then this was my initial idea as well - but then the configs could be more or less emtpy if all parameters are the same. This has a couple of disadvantages:
- When looking at the config online people cannot see any parameters and would have to look into the code which might be annoying
- This would make the configs much more prone to break if the init values of respective classes are changed.

**UPDATE**: I had to add a class attribute to the config to make this feature work (see description above) - @julien-c @sgugger @thomwolf @LysandreJik - could you check if this is fine for you guys.

LGTM