Add on_resize to xterm and show how to use it in xterm example

[jacopofar]

Motivation

This tries to implement a solution to the issue described in #5847

The idea is to make it easier to detect xterm size changes (with an handler+event with proper types) and extend the xterm example with code to handle the resize and communicate it to the process, plus a comment to explain how to test it.

Implementation

This implements the change suggested in the original discussion to expose on_resize as an handler with an event using the proper type (the resize event was already available using terminal.on('resize', ...), now it's simply available as an handler with a typed event.

The logic to send the control codes requires a pty and so it cannot be incorporated in the xterm element but it has to be in the caller.

There are two things on which I have doubts:

• The changes with the original xterm example are so small I didn't create a new example but extended the original one, assuming many want to know how to do this
• The logic to send the control codes is a bit obscure and require some imports, but I didn't find a nice way to have it incorporated in the xterm element itself. A possible way would be to create a separate PtyXterm element or something like that that already starts a command and a pty and handles it internally. How does it sound?

Progress

• I chose a meaningful title that completes the sentence: "If applied, this PR will..."
• The implementation is complete. (Note: @evnchn thought so)
• If this PR addresses a security issue, it has been coordinated via the security advisory process.
• Pytests have been added (or are not necessary).
• Documentation has been added (or is not necessary).
  • But can we make it into NiceGUI website? Though it sounds very tough...

[evnchn]

@jacopofar could you get pre-commit and pylint happy? Thanks 🙏🏻

[jacopofar]

Yep, sorry about that

[evnchn]

Nice, @jacopofar. Two tips:

1. If you enable github actions for your fork, you don't need me to trigger the github actions run.
2. We tend to do merge, not rebase, when a PR is active.

Though for 2 you made a good call since we need the KWONLY_SLOTS deprecation, otherwise we don't do it unless something in main we really need.