No indication of where updated contents were written

[arxanas]

Steps to reproduce

Create test.md with these contents:

Here is a test:

```scrut
$ echo hi
```

Run scrut update test.md:

$ scrut update test.md
// =============================================================================
// @ test.md:4
// -----------------------------------------------------------------------------
// # Here is a test:
// -----------------------------------------------------------------------------
// $ echo hi
// =============================================================================

   1  | + hi


Result: 1 file(s) of which 1 updated, 0 skipped and 0 unchanged

Expected behavior

• There's some indication of where the updated contents were written.
• There's some indication that updated contents were not written in-place.

Actual behavior

• Silently writes to test.md.new, without making it clear where the updates have gone.

It's confusing because I was expecting updates to be applied automatically like some snapshot testing frameworks, but that didn't happen, yet scrut update succeeded without error.

Some options to improve the UI:

• For each test, print something like wrote updated contents to test.md.new
• At the end of the test run, print a command that can be used to accept the changes

[AndreasBackx]

It should have updated the new file. I'm just signing off for today as it's late here in London. Though we'll have a look at why it's not updating the original file and get back you to.

[arxanas]

@AndreasBackx to be clear, I don't think there's a correctness bug here, just a UI bug. It does update test.md.new successfully, but nothing in the scrut output would let me know that. I have to basically check git status to see that there's a new file.

[ukautz]

Scrut logs the output file location, but only in info-level. Unfortunately the default level is warn, hence it's not visible (unless RUST_LOG=info). Why logging is used here instead of eprintln has some historic reasons and kinda makes sense for our own use-case.

Either way I agree this is an UI bug and this should be better communicated. However, this is not an isolated issue, but all output (especially info level in the commands) should be reviewed.