DeltaTest improvements

[WayneD]

• Added .expect_contains(), .expect_raw_contains(), and .expect_contains_once() member functions to DeltaTestOutput. These functions also output some helpful debug info when the assert fails.
• Separated .with_config_and_input() into .with_config() and (the tweaked) .with_input().
• Made .with_config() create a DeltaTest object (like .with() does).
• Renamed .with() as .with_args().
• Moved .explain_ansi() from DeltaTestOutput to DeltaTest, which must now be called prior to .with_input() since the latter stashes off both the raw_output & the processed output in the object.
• Changed .expect() and .expect_skip() to return Self so that they can continue a chain of multiple expect calls (e.g. a series of partial matches with different skip values).
• The processed output text can be accessed via test_obj.output (see also test_obj.raw_output).
• Renamed .expect_skip() to .expect_after_skip().
• Changed .expect() to start at the first line.
• Added .expect_after_header() that works like the old .expect().
• Renamed lines_match() to assert_lines_match() and made it match all lines (no skip number).
• Added assert_lines_match_after_skip() to work like the old lines_match() function, but with the .expect_after_skip() arg order.
• Converted some old-style tests into DeltaTest style tests.

[dandavison]

cc @th1000s who's the creator of DeltaTest.

[th1000s]

If calling with_config(config: config::Config) using the same config multiple times happens more often in the future then storing a Cow<'a, &Config> might help as well. Which is what you have been reimplementing manually anyhow :)

tweaking someone else's code.

Oh please do, nothing helps more than someone who didn't write the code noticing that the names or logic are not as clear as they could be. Maybe also rename set_cfg to set_config?

[dandavison]

This PR is great IMO Wayne, and I'm glad to hear that Thomas approves.

Maybe also rename set_cfg to set_config

That SGTM. Do you want to make that final change and then I'll merge this?

[dandavison]

Thanks again for this Wayne.

If calling with_config(config: config::Config) using the same config multiple times happens more often in the future then storing a Cow<'a, &Config> might help as well.

My first thought was to try to use Cow, but there were errors: our Config is not clone-able, and yet my understanding is that Cow needs to be able to create an owned version of a data structure from a reference. I tentatively concluded that what we needed was not exactly Cow but an even simpler enum over owned|reference which supports borrowing, but I didn't think it through / investigate properly.

I do see you've written &Config there, whereas what I tried was Cow<'a, Config> I think.

[th1000s]

Indeed, Cow<&Config> is nonsense. Making Config cloneable required a few derives and a hack for GitConfig, see #884