Re: [PATCH v3] git-prompt: make colourization consistent

This is not a new issue, but seeing this:

 	if [ $detached = no ]; then
 		branch_color="$ok_color"
 	else
 		branch_color="$bad_color"
 	fi
 	c="$branch_color$c"
 
 	z="$c_clear$z"
 	if [ "$w" = "*" ]; then
 		w="$bad_color$w"
 	fi
 	if [ -n "$i" ]; then
 		i="$ok_color$i"
 	fi
 	if [ -n "$s" ]; then
 		s="$flags_color$s"
 	fi
 	if [ -n "$u" ]; then
 		u="$bad_color$u"
 	fi
+	if [ -n "$p" ]; then
+		p="$c_clear$p"
+	fi
+	if [ -n "$sparse" ]; then
+		sparse="$c_clear$sparse"
+	fi
 	r="$c_clear$r"
 }

it makes me wonder if the more forward looking and future-proof way that is resistant to any future and random reshuffling like what 0ec7c23c (git-prompt: make upstream state indicator location consistent, 2022-02-27) did would be to make it a rule to maintain that there is no coloring by default, and when any of these tokens like w, i, s, ... are not empty, enclose them inside "color-on" and "color-off" sequence.

For example, 

 	if [ "$w" = "*" ]; then
 		w="$bad_color$w"
 	fi

would mean $w, when it is "*", would cause gitstring to contain an asterisk that is painted in $bad_color, but ALSO causes whatever that happens to come AFTER $w in gitstring to be painted in the same color UNLESS it tries to protect itself. Right now, $w may be immediately followed by $i, and $i does protect itself by prefixing with $ok_color, but if $i is empty, $w's coloring will extend to $s.

So, if we did this instead:

- 	z="$c_clear$z"
 	if [ "$w" = "*" ]; then
- 		w="$bad_color$w"
+ 		w="$bad_color$w$c_clear"
 	fi

and make similar changes to everything else we see above, we probably can lose the ones that prefix with $c_clear, because each token that paints itself in unusual color is now responsible for returning the terminal state to normal with the $c_clear sequence after it is done with it. We do not have to special case sparse, p, or r in this helper function at all if we go that route, no?

If the helper were written that way, then reshuffling the order of the tokens done in 0ec7c23c (git-prompt: make upstream state indicator location consistent, 2022-02-27) wouldn't have made the patch under discussion necessary at all, which is what I see is valuable from the "maintainability" point of view.