Backtraces on commands apply

[alec-deason]

I often run into a bad debugging experience where a Command fails during writing and it's very hard to track down which system actually caused the issue because the backtrace is all inside bevy_ecs. I'd like to have backtraces captured when the Command was actually written to the buffer.

This change adds a new feature flag called "command_backtraces" which causes a failed Command to print a trace of the stack when it was added to the buffer as well as a trace of the actual failure point. It is gated by a feature because it depends on std::backtrace which is a nightly only API and because recording the backtraces will have some performance impact (though I haven't actually measured how large it is).

The primary thing I am concerned about in this PR is the way I've introduced the Result return into Command implementations. I don't feel like I have good intuition about best practice error handling in Rust so I'd love feedback about clarity and idiomicity (which is surely a word?).

[alec-deason]

One other potential concern with this change. I was worried that it would reduce the usefulness of the backtraces from the actual failure point inside the Command but because of how anyhow captures and displays backtraces I don't think that's actually an issue unless there's a case I'm not noticing.

[joshuajbouw]

Please rebase

[alec-deason]

It's been a while since I did a rebase and I think that could have been done better.... But it should be consistent with master now.

I'm even less satisfied with the error handling after these changes though. I ended up doing a bunch of anyhow!("{:?}", e) type conversions and that feels wrong to me.

[bjorn3]

and because recording the backtraces will have some performance impact (though I haven't actually measured how large it is).

The performance impact of stack unwinding is non-trivial. Even when it is only done for a backtrace and not to perform cleanup after a panic. DWARF based unwinding requires searching through .eh_frame for the current function, interpreting all unwind instructions and then repeating it again for the parent function and so on.

[alec-deason]

@alice-i-cecile I don't think the ready for cart label is appropriate on this one. There has been some discussion on discord about the state of error handling in this and a suggestion to use track_caller to resolve some of the concerns. But I haven't followed up on those yet.

[NathanSWard]

I believe this can be closed in favor of #2241

[alice-i-cecile]

Closing in favor of #2241 <3