Handling of Zero-Width escapes in PS1

[benbe1987]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-parentheses -Wno-format-security
uname output: Linux desktop 5.0.3-050003-generic #201903191333 SMP Tue Mar 19 
13:35:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 19
Release Status: release

Description:
        When setting up a complex PS1 prompt where parts of the
        prompt is expanded on every new prompt displayed by bash
        the escape sequences that are generated by that dynamic
        part are handled improperly (read: not at all).

        The desired behaviour should treat such escapes for e.g.
        the sequences \[ and \] equal both when the prompt expands
        to stuff\[stuff\]stuff, regardless of whether this was
        reached by "stuff$(echo \[stuff\])stuff" (\[\] handled) or
        reached by 'stuff$(echo \[stuff\])stuff' (not handled) being
        set as the value of PS1.

Repeat-By:
        To demonstrate this odd behaviour assume some command
        that displays changing information at each invokation:

        __test1(){ echo -e "Random is \\[\e[37;1m\\]$RANDOM\e[0m"; }

        Now let's assume two cases:

        Case 1:
        PS1='Test$(__test1)Test\[\e[0m\]$ '
        -> Shows \[\] markers, includes output of $(__test1) dynamically

        Case 2:
        PS1="Test$(__test1)Test\[\e[0m\]$ "
        -> Displays correct, but statically includes output of $(__test1)

        The desired behaviour is dynamic inclusion of $(__test1) as with
        case 1 while having the \[\] markers respected as seen in case 2.

        Splitting the output of __test1 to separate sections with
        \[\] markers and such which don't need them is not possible,
        as the number of such sections may vary and the limited syntax
        of PS1 does not allow for loops and other conditional constructs
        on its top level.

        Also leaving out the \[\] markers from __test1 will cause the
        displayed prompt to misbehave.

Fix:
        Move handling of \[ and \] markers to be done on the fully
        expanded, representation of the PS1 variable after variable
        substitutions and subshell output have been inserted.