Add OSC 133 prompt markers to ansi Handler

[nixpulvis]

Route OSC 133 ;A, ;B, ;C, and ;D to four new Handler methods: prompt_start, prompt_end, command_start, and command_end, so emulators can track shell prompt and command regions. command_end parses the optional exit code from the OSC 133 ; D ; <code> form. All four methods default to no-ops, so existing consumers are backwards compatible.

OSC 133 is emitted by shells, e.g. fish or by zsh with the vendor_conf.d integrations and bash with bash-preexec, starship, and other integrations. The four sub-commands delimit prompt and command regions and let the terminal track shell state in this way. Other terminals like kitty and ghostty also consume this protocol.

The primary motivation for this for me is alacritty/alacritty#8961.

[chrisduerr]

I'm willing to merge this as long as any terminal emulator making use of VTE is interested in this, even if Alacritty does not receive support.

If it turns out OSC 133 is not useful to Alacritty, I'd imagine cosmic-term would still be interested in this (and a possible API in alacritty_terminal maybe).

[nixpulvis]

Review comments should be addressed, and I've also updated the naming of the handler methods to actually match the spec and be much less confusing.

and a possible API in alacritty_terminal maybe

I was thinking a bit more about this, and regardless of the state of alacritty/alacritty#8961 or our intentions of merging it, changing it significantly, or just leaving it, I think a better API to the underlying OSC 133 regions would be nice. I'm not sure if this is the right thread for it though, so I'll try to post some thoughts in alacritty/alacritty#5850 soon.

[chrisduerr]

This documentation is not particularly helpful unless you already know what it's talking about.

Suggested change

	/// Set on `command_start` or `command_executed` and cleared on
	/// `command_finished`. Used to ignore `command_finished` when not set.
	/// Prompt marker state.
	///
	/// Used to track whether we're inside a prompt region with marked boundaries. See [`Handler::command_finished`].

[chrisduerr]

This is only necessary if execution is possible without start, right? iterm2's document suggests this is not allowed, though it's not entirely clear about that.

Generally it doesn't really cover edgecases very well…

[nixpulvis]

It says this:

All text between FTCS_COMMAND_START and FTCS_COMMAND_EXECUTED at the time FTCS_COMMAND_EXECUTED is received excluding terminal whitespace is considered the command the user entered.

Which I don't interpret as a strict requirement, but more of an "if there is text, it's interpreted this way" kind of statement.

It then goes on to say this:

It is expected that user-entered commands will be edited interactively, so the screen contents are captured without regard to how they came to contain their state. If the cursor's location is before (above, or if on the same line, left of) its location when FTCS_COMMAND_START was received, then the command will be treated as the empty string.

Which explicitly allows for the case of a command being empty, even if it's not directly about sending C without B.

Given that, I feel like it's reasonable to allow for this, though I really don't have a strong feeling about it right now.

I do feel like I need to do a survey of existing OSC 133 supporting shells and applications.

[chrisduerr]

To me the statement regarding FTCS_COMMAND_START suggests that you need to know about the command start to know whether it's empty or not. If you don't have this information, you won't be able to tell whether it should be empty or not.

It's fair to just assume it shouldn't be empty if you have no information, but it's not entirely clear (imo).