Cleanup load_weight_prefix in TFEncoderDecoderModel
# What does this PR do?

## Short
In `TFEncoderDecoderModel`, there is `tf_encoder_decoder_model_1` (with the strange ending `_1`)

https://github.com/huggingface/transformers/blob/68810aa26c083fd97d976cef7ac65fdd9cc9b520/src/transformers/models/encoder_decoder/modeling_tf_encoder_decoder.py#L158

This PR change it to `tf_encoder_decoder_model` to avoid confusion

## Long

I originally looked `TFRagModel` code during a (long) process to make checkpoint loading work.
While it works, it gave me the wrong impression that `_1` is necessary.

As @LysandreJik  and @NielsRogge  both asked this question

https://github.com/huggingface/transformers/pull/13222#discussion_r725279027
https://github.com/huggingface/transformers/pull/14148#discussion_r780361966

I gave it a try and also reviewed the code
https://github.com/ydshieh/transformers/blob/e68c3756fea7c811d02b8470539ae17ec3ec0e71/src/transformers/modeling_tf_utils.py#L496

It turns out that the `_1` is not necessary, and therefore the recent model `TFVisionEncoderDecoderModel` doesn't use `_1`.
To avoid further confusion (and avoid this confusion being copied in future TF composite models), I think it's better to clean it up here.

## Who can review?

 -->

Thank you @ydshieh for your contribution!

From recent conversations with @patrickvonplaten and @Rocketknight1, I think this is actually important and cannot be removed, right? I'll let them chime in :)<|||||>I'm not aware of any reason to keep the `_1`, but then again I don't know why it was there in the first place! <|||||>> I'm not aware of any reason to keep the `_1`, but then again I don't know why it was there in the first place!

Before these TF encoder-decoder models, the only place that has `load_weight_prefix` with ending `_1` is in `TFRagModel`.
And when I worked on TF enc-dec models, I copied the idea from it in order to make the weight loading work correctly - and it somehow gave me wrong impression of the necessity of `_1` - and this is why it was there in the first place.



<|||||>In short we can safely remove the `_1` - it won't change anything. It actually doesn't matter at how we call the first prefix of the weight names, as we always remove them later.

For more context and to maybe understand a bit better how to load TF models you can do the following:

1. Download a raw `h5` file from the hub, *e.g.*:
```bash
wget https://huggingface.co/ydshieh/vit-gpt2-coco-en/resolve/main/tf_model.h5
```
2. Now run the following code. This is essentially what we are doing in TF's `from_pretrained(...)` to retrieve the weight names:
```python
import h5py
from tensorflow.python.keras.saving import hdf5_format

with h5py.File("./tf_model.h5", "r") as f:
    layer_names = set(hdf5_format.load_attributes_from_hdf5_group(f, "layer_names"))
    weight_names= set(hdf5_format.load_attributes_from_hdf5_group(f[layer_names.pop()], "weight_names"))

    print(weight_names)
```

The output looks something like this:

```bash
{ ...,
'tf_vision_encoder_decoder_model/encoder/vit/encoder/layer_._9/layernorm_after/beta:0', 'tf_vision_encoder_decoder_model/encoder/vit/encoder/layer_._8/attention/attention/query/bias:0'}
```

3. Note that the very first prefix was never actually written by us. We don't call any layer or weight `tf_vision_encoder_decoder_model`, *i.e.* there is no `self.tf_vision_encoder_decoder_model = ...` statement anywhere. Those weight names are generated automatically by TF's saving method. I believe that in previous TF versions (I'm using 2.7.0 now) - TF also automatically appended a `_0` or `_1` there. 

4. Since this very first prefix is not written by us, but since it'll always automatically be created by TF, we've decided to **always** remove it when loading the model - see: https://github.com/huggingface/transformers/blob/b8810847d0576e3c142854ad3b8a607ecd3df291/src/transformers/modeling_tf_utils.py#L550

5. Now composite models like `TFEncoderDecoder` are very special because we need to give them some prefix weight name in order to correctly load. It doesn't matter though really what kind of name we give it as long as there is something that can be correctly cut away by the above line of code.


=> As a conclusion, I think it's a good idea to remove `_1` as it can be a bit confusing for the reader.
<|||||>Ok, thanks for the clarification @patrickvonplaten! <|||||>@Rocketknight1 please do merge if you're ok with the changes.<|||||>LGTM, merging now!