Refactor slow sentencepiece tokenizers.
PR for #11646

## ToDo

- [x] `AlbertTokenizer`
- [x] `BarthezTokenizer`
- [x] `BertGenerationTokenizer`
- [x] `BigBirdTokenizer`
- [x] `CamembertTokenizer`
- [x] `DebertaV2Tokenizer`
- [x] `M2M100Tokenizer`
- [x] `MarianTokenizer`
- [x] `MBart50Tokenizer`
- [x] `PegasusTokenizer`
- [x] `ReformerTokenizer`
- [x] `Speech2TextTokenizer`
- [x] `T5Tokenizer`
- [x] `XLMProphetNetTokenizer`
- [x] `XLM RoBERTa`
- [x] `XLNetTokenizer`
`SentencePieceProcessor.decode` is doing "the same but more than `SentencePieceProcessor.decode_pieces`. 
That is why we replace `SentencePieceProcessor.decode_pieces` with `SentencePieceProcessor.decode` in this PR.

See here:

https://github.com/google/sentencepiece/blob/6256ef243844e5848499cf519eb2a7e2755e75a1/python/src/sentencepiece/__init__.py#L307<|||||>rebased on upstrem/master<|||||>We need to rebase on master after PR #11737 has been merged.<|||||>Rebased on master - CI is green again. :-) <|||||>Rebased on master to get integration tests - see #11737<|||||>Rebased on master<|||||>> I think generally speaking we'd like to have methods that are common to all tokenizers in the base class - but not methods that are common to some of them only. I'd also like to keep the number of abstraction layers to a minimum, tokenizers are already quite tough to understand.

@LysandreJik 
Yes. I also prefer a low number of abstraction layers. At the same time I like dry code. There is 100% duplicate code in the tokenizers impl. that has just been duplicated by copy & paste. IMO that should be removed by an refactoring. That is what I try to introduce here.<|||||>The general approach of the library is to keep the number of abstractions as low as possible, and to keep implementations as separate as possible from each other, hence the high amount of copy-pasted code.

We want users to be able to experiment with single models/tokenizers without their changes impacting other models or tokenizers - and we want them to be able to understand how a model or tokenizer behaves by simply checking a single file, rather than having to hop around multiple files.

We are failing at this with tokenizers as there are already two levels of abstraction, but adding a third one isn't really the direction we want to head to :)

Does that make sense?<|||||>> Does that make sense?

Yes. Sure. Your project, your call.
I will revert my changes and keep it as simple as possible as discussed in the beginning.
<|||||>@LysandreJik I have redone the PR. Everything is green and the changes are as simple as planned in the issue.
This is ready for review.

Averything is tested by setting `test_sentencepiece = True` in the tokenizer test classes and by the following 
testfunction: `TokenizerTesterMixin.test_sentencepiece_tokenize_and_convert_tokens_to_string`