Extend config with task specific configs.
As discussed and proposed by @thomwolf in PR #3413, another step towards a combined tokenizer/model config is this PR. It extends the normal config with the following parameters: 

```
{
....
prefix = "", # generic generation HP
max_length: 100,  
length_penalty: 1.0,
task_specific_params: {
     "summarization": {  # task id (e.g. name of the pipeline?)
          max_length: 140,
          length_penalty: 2.0
      },
     "translation_en_to_de": {
          prefix: "translate English to German: "
          max_length: 160,
          length_penalty: 3.0
      },
    },
}
```

In terms of hierarchy for a task-specific generation it would go as follows:
1) Is the parameter provided as an argument to the `generate` method ? Yes use these. No - go to 2.
2) Is the parameter provided in the `task_specific_params dict` ?  Yes use these. No - go to 3.
3) Is the parameter provided in the default `config dict`? Yes use these. No - go to 4.
4) Is the parameter provided hard-coded in the model's config file? Yes use these. No - use the very default parameters of `PretrainedConfig`


These were our arguments in favor of this: 

- This removes a lot of hard coded parameters in pipelines and examples
- Another step towards a combined tokenizer / model config
- A lot of weird if-else statements can be saved ("If task is en-de translation then do X" won't be necessary as the en-de specific parameters will override the default ones)

### TODO

If you guys are fine with this structure:

- [ ]  I will add the `task_specific_params` for Bart and T5s configs on S3 
- [ ] clean up the examples and pipelines.
- [ ] rebase all the T5s PRs: #3428, #3419, #3413, #3411
> I think this makes sense, giving where we've been going up to now.
> 
> I would like to understand what is our philosophy with the growing size of the configuration files; for example the `bert-base-cased` configuration on S3 looks like this:
> 
> ```
> {
>   "architectures": [
>     "BertForMaskedLM"
>   ],
>   "attention_probs_dropout_prob": 0.1,
>   "hidden_act": "gelu",
>   "hidden_dropout_prob": 0.1,
>   "hidden_size": 768,
>   "initializer_range": 0.02,
>   "intermediate_size": 3072,
>   "max_position_embeddings": 512,
>   "num_attention_heads": 12,
>   "num_hidden_layers": 12,
>   "type_vocab_size": 2,
>   "vocab_size": 28996
> }
> ```
> 
> (which is readable imo) and once it's saved it now looks like this:
> 
> ```
> {
>   "_num_labels": 2,
>   "architectures": [
>     "BertForMaskedLM"
>   ],
>   "attention_probs_dropout_prob": 0.1,
>   "bos_token_id": null,
>   "do_sample": false,
>   "early_stopping": false,
>   "eos_token_id": null,
>   "finetuning_task": null,
>   "hidden_act": "gelu",
>   "hidden_dropout_prob": 0.1,
>   "hidden_size": 768,
>   "id2label": {
>     "0": "LABEL_0",
>     "1": "LABEL_1"
>   },
>   "initializer_range": 0.02,
>   "intermediate_size": 3072,
>   "is_decoder": false,
>   "is_encoder_decoder": false,
>   "label2id": {
>     "LABEL_0": 0,
>     "LABEL_1": 1
>   },
>   "layer_norm_eps": 1e-12,
>   "length_penalty": 1.0,
>   "max_length": 20,
>   "max_position_embeddings": 512,
>   "min_length": 0,
>   "model_type": "bert",
>   "no_repeat_ngram_size": 0,
>   "num_attention_heads": 12,
>   "num_beams": 1,
>   "num_hidden_layers": 12,
>   "num_return_sequences": 1,
>   "output_attentions": false,
>   "output_hidden_states": false,
>   "output_past": true,
>   "pad_token_id": 0,
>   "pruned_heads": {},
>   "repetition_penalty": 1.0,
>   "temperature": 1.0,
>   "top_k": 50,
>   "top_p": 1.0,
>   "torchscript": false,
>   "type_vocab_size": 2,
>   "use_bfloat16": false,
>   "vocab_size": 28996
> }
> ```
> 
> (which is less readable), are we planning to keep them growing as the tokenizer and model configurations are merged? I feel like adding all those attributes to the configuration saves an "experiment" more than a "model". Is this something we're aiming for?

Might it be possible to only save parameters that are different from the default config of the corresponding model? This would keep it readable. <|||||>LGTM and I agree with what @LysandreJik and you just said above. Serialized `config.json` should be more minimal. 

For instance I've always disliked the `id2label` and `label2id` being serialized even for models that don't have a classification head.<|||||>After this is merged I can open a new PR that serializes only the non-default values.<|||||>I agree with what @LysandreJik and @julien-c says about serializing only non-default values by the way.