Fixed: Improve handling of empty ';' SGR sequences

[fornwall]

Currently the Termux terminal emulator prints HI in red with:

printf "\e[31;m HI \e[0m"

This is not how other terminals (tested on xterm, gnome-terminal, alacritty and the mac built in terminal) handle it, since they parse \e[31;m as \e[31;0m, where the 0 resets the colors.

This change aligns with other terminals, as well as improves performance by avoiding allocating a new int[] array for each byte processed by parseArg(), and most importantly simplifies things by removing the mIsCSIStart and mLastCSIArg state, preparing for soon supporting : separated sub parameters such as used in
https://sw.kovidgoyal.net/kitty/underlines/

[trygveaa]

Note that WezTerm and kitty also print the text in red with this example. Reading the ECMA-48 specification (which is the one that defines this sequence) it does seem correct to reset the color, but it looks like the standard contradicts itself a bit.

Section 5.4.2 e about CSI says:

An empty parameter sub-string represents a default value which depends on the control function

And section 8.3.117 about SGR says:

Parameter default value: Ps = 0

However 5.4.2 h also says:

However, if the last parameter sub-string(s) is empty, the separator preceding it may be omitted, see B.2 in annex B.

And B.2 says:

6; 03/06 03/11 Two parameters, the first having the value 6 and the second taking the default value. NOTE - The bit combination 03/11 may be omitted (see 5.4.2 h).

So the first two quotations says that \e[31;m should be equal to \e[31;0m, but the last two quotations says it should be equal to \e[31m. However, given how this control code works \e[31;0m can't be equal to \e[31m (then it wouldn't be possible to set any colors).