Use track_caller approach for logging from a method

[lionel-]

I noticed that Zed uses the track_caller approach in the log methods of their extension trait for Result: https://github.com/zed-industries/zed/blob/a910c594d6c5f6a808aa3c45ca4f8e5bba66ae75/crates/util/src/util.rs#L554

We've already used that track_caller feature to great effect in #955.

They also have neat methods such as debug_assert and anyhow.

This PR removes the existing disparate infra we have for logging errors to use that new trait.

Compared to log_error!:

• The methods have postfix syntax, which is often nicer especially when you don't want to obscure the main logic.
  I was a bit confused when I stumbled upon this today:

  log_error!(tx.send(msg));

  This made it seem the logging was unconditional.

Compared to ResultOrLog:

• The log_err() method does not require adding context. I think that's helpful for things like .send() to a channel where you don't quite want to panic if not related to essential channels, but you don't want to add too much clutter/overhead to the error handling either. You can still add context if you want to with anyhow's .context() method.
• We do a better job of forwarding error backtraces.
• We propagate caller info (line/file).
• Because we now display backtraces that can be quite long, and because log displays file/line info after the error message, we manually reiterate the file/line info before the message so the emitter of the log message is immediately identifiable.

Before with ResultOrLog:

fail("ouch").or_log_error("that hurts");

• No backtrace
• Wrong file/line

After with ResultExt:

fail("ouch").context("that hurts").log_err();

• Backtrace
• Correct file/line on top
• Nicely formatted context

[DavisVaughan]

Cool!