add -i: verify in the tests that colors can be overridden

Now that the Perl version produces the same output as the built-in version (mostly fixing bugs in the latter), let's add a regression test to verify that it stays this way. Note that we only `grep` for the colored error message instead of verifying that the entire `stderr` consists of just this one line: when running the test script using the `-x` option to trace the commands, the sub-shell in `force_color` causes those commands to be traced into `err.raw` (unless running in Bash where we set the `BASH_XTRACEFD` variable to avoid that). Also note that the color reset in the `<BLUE>+<RESET><BLUE>new<RESET>` line might look funny and unnecessary, as the corresponding `old` line does not reset the color after the diff marker only to turn the color back on right away. However, this is a (necessary) side effect of the white-space check: in `emit_line_ws_markup()`, we first emit the diff marker via `emit_line_0()` and then the rest of the line via `ws_check_emit()`. To leave them somewhat decoupled, the color has to be reset after the diff marker to allow for the rest of the line to start with another color (or inverted, in case of white-space issues). Finally, we have to simulate hunk editing: the `git add -p` command cannot rely on the internal diff machinery for coloring after letting the user edit a hunk; It has to "re-color" the edited hunk. This is the primary reason why that command is interested in the exact values of the `color.diff.*` settings in the first place. To test this re-coloring, we therefore have to pretend to edit a hunk and then show that hunk in the regression test. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>