Use text_format for Tour content (+ WYSIWYG UI)

Problem/Motivation

Tour module historically uses Xss:filterAdmin() for the Text Tips: https://git.drupalcode.org/project/tour/-/blob/2.0.x/src/Plugin/tour/tip...

The filtering happens through:

 /**
   * {@inheritdoc}
   */
  public function getBody(): array {
    return [
      '#type' => 'html_tag',
      '#tag' => 'p',
      '#value' => $this->token->replace($this->get('body')),
      '#attributes' => [
        'class' => ['tour-tip-body'],
      ],
    ];
  }

https://git.drupalcode.org/project/tour/-/blob/2.0.x/src/Plugin/tour/tip...
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...

In some cases this might be too restrictive and Drupal already has a great solution for that: Using text_format!
I think, if the module (with UI) had been done from scratch, that would surely have been used and the UI would have shown the WYSIWYG plus text format selection.

Our specific case is adding videos to the tooltips, but media embed and video tags are not supported. Still I'm sure, especially when using the UI, users would be happy to be able to use all WYSIWYG and text filter features!

Discussion:

I see two possible ways of solving this:

a) Add a further Tip Plugin and schema: TipPluginTextFormat
Simlar to https://git.drupalcode.org/project/tour/-/blob/2.0.x/src/Plugin/tour/tip...

or

b) Keep and upgrade the TipPluginText → to use text_format instead of text in the Schema and in the Input / Output.
That would mean we need an update hook to update all the existing configs and we'd also need to determine the text format to filter by (which seems quite hard or at least risky)

(b) seems harder, but would be clearer UX in the future, I guess, instead of having two very similar Tip Types, but it's quite risky for breaking existing installations?
(a) should be quite easy and could even be done in contrib or a submodule, while I'd clearly vote to add this very useful functionality in the module itself!

@Maintainers: Would be super nice to get some feedback, then we'd implement this accordingly.

Steps to reproduce

See above

Proposed resolution

See above (a) or (b)

Remaining tasks

1. Discuss
2. Implement
3. Test
4. Release

User interface changes

API changes

Data model changes