Easily train a new fast tokenizer from a given one - tackle the special tokens format (str or AddedToken)
# What does this PR do?

<!--
Congratulations! You've made it this far! You're not quite done yet though.

Once merged, your PR is going to appear in the release notes with the title you set, so make sure it's a great title that fully reflects the extent of your awesome contribution.

Then, please replace this with a description of the change and which issue is fixed (if applicable). Please also include relevant motivation and context. List any dependencies (if any) that are required for this change.

Once you're done, someone will review your PR shortly (see the section "Who can review?" below to tag some potential reviewers). They may suggest changes to make the code even better. If no one reviewed your PR after a week has passed, don't hesitate to post a new comment @-mentioning the same persons---sometimes notifications get lost.
-->

This PR is a sub-PR of the feature developed in PR #12361.

In the `train_new_from_iterator` method, the user can indicate that he wants to change the wording of a special token with the `special_tokens_map` argument. 

In terms of behavior, we expect the resulting tokenizer to have special tokens that behave like the special tokens that were in the initial tokenizer. In other words, if in the initial token the special token linked to the `mask_token` was an `AddedToken` with `lstrip=True` then this parameter must be kept in the new trained tokenizer even if the user in the `special_tokens_map` argument indicates that the wording changes. For example from `[MASK]` to `<mask>`.

This PR proposes this behavior and tests it
