git-prompt: make colourization consistent

The short upstream state indicator inherits the colour of the last short state indicator before it (if there is one), and the sparsity state indicator inherits this colour as well. This behaviour was introduced by 0ec7c23cdc6 (git-prompt: make upstream state indicator location consistent, 2022-02-27), while before this change the aforementioned indicators were white/the default text colour. Some examples to illustrate this behaviour (assuming all indicators are enabled and colourization is on): * If there is something in the stash, both the '$' and the short upstream state indicator following it will be blue. * If the local tree has new, untracked files and there is nothing in the stash, both the '%' and the short upstream state indicator will be red. * If all local changes are added to the index and the stash is empty, both the '+' and the short upstream state indicator following it will be green. * If the local tree is clean and there is nothing in the stash, the short upstream state indicator will be white/${default text colour}. This appears to be an unintended side-effect of the change, and makes little sense semantically (e.g. why is it bad to be in sync with upstream when you have uncommitted local changes?). The cause of the change in colourization is that previously, the short upstream state indicator appeared immediately after the rebase/revert/bisect/merge state indicator (note the position of $p in $gitstring): local f="$h$w$i$s$u" local gitstring="$c$b${f:+$z$f}${sparse}$r$p" Said indicator is prepended with the clear colour code, and the short upstream state indicator is thus also uncoloured. Now, the short upstream state indicator follows the sequence of colourized indicators, without any clearing of colour (again note the position of $p, now in $f): local f="$h$w$i$s$u$p" local gitstring="$c$b${f:+$z$f}${sparse}$r${upstream}" If the user is in a sparse checkout, the sparsity state indicator follows a similar pattern to the short upstream state indicator. However, clearing colour of the colourized indicators changes how the sparsity state indicator is colourized, as it currently inherits (and before the change referenced also inherited) the colour of the last short state indicator before it. Reading the commit message of the change that introduced the sparsity state indicator, afda36dbf3b (git-prompt: include sparsity state as well, 2020-06-21), it appears this colourization also was unintended, so clearing the colour for said indicator further increases consistency. Make the colourization of these state indicators consistent by making all colourized indicators clear their own colour. Make colouring of $c dependent on it not being empty, as it is no longer being used to colour the branch name. Move clearing of $b's prefix to before colourization so it gets cleared properly when colour codes are inserted into it. These changes make changing the layout of the prompt less prone to unintended colour changes in the future. Change coloured Bash prompt tests to reflect the colourization changes: * Move the colour codes to wrap the expected content of the expanded $__git_ps1_branch_name in all tests. * Insert a clear-colour code after the symbol for the first indicator in "prompt - bash color pc mode - dirty status indicator - dirty index and worktree", to reflect that all indicators should clear their own colour. Signed-off-by: Joakim Petersen <joak-pet@online.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>