add a test checking the format of `convert_tokens_to_string`'s output
# What does this PR do?

For context, the tokenizers 0.12.0 release was breaking in the sense that it changed the output format of the `decode` method of the `backend_tokenizer` 's `decoder` which was used in `convert_tokens_to_string` (cf #16537, #16520, #16525). The 0.12.0 version has since been yanked but I think it would be beneficial to add a common test to the transformers tokenizers to verify that the `convert_tokens_to_string` method output format is respected.

This PR therefore proposes adding such tests with some overridden tests for tokenizers with constraints on possible tokens or with a slightly different output format.


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [ ] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/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.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] 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. Would love to have your opinion @LysandreJik , @sgugger and/or @Narsil 

_The documentation is not available anymore as the PR was closed or merged._<|||||>Thanks for the review @Narsil :slightly_smiling_face: 

> Why is tokenization_common test not enough ? Don't the other tests inherit the same base/meta class ?

They also inherit from `TokenizerTesterMixin`, but unfortunately there are 1) tokenizers that have constraints on acceptable tokens - this is the case of `ByT5`  and `perceiver` - and 2) tokenizers whose `convert_ids_to_string` method returns not a string but a dictionary - this is the case of `wav2vec2` and `wav2vec2_phoneme`.<|||||>Thanks for the explanation, definitely not obvious !<|||||>That a good point: I've added a comment for each overridden test in my last commit to reflect that last explanation :slightly_smiling_face: 