Implement SystemCondition for systems returning Result<bool, BevyError> and Result<(), BevyError>

[gwafotapa]

Objective

Fixes #19403
As described in the issue, the objective is to support the use of systems returning Result<(), BevyError> and
Result<bool, BevyError> as run conditions. In these cases, the run condition would hold on Ok(()) and Ok(true) respectively.

Solution

IntoSystem<In, bool, M> cannot be implemented for systems returning Result<(), BevyError> and Result<bool, BevyError> as that would conflict with their trivial implementation of the trait. That led me to add a method to the sealed trait SystemCondition that does the conversion. In the original case of a system returning bool, the system is returned as is. With the new types, the system is combined with map() to obtain a bool.

By the way, I'm confused as to why SystemCondition has a generic In parameter as it is only ever used with In = () as far as I can tell.

Testing

I added a simple test for both type of system. That's minimal but it felt enough. I could not picture the more complicated tests passing for a run condition returning bool and failing for the new types.

Doc

I documenting the change on the page of the trait. I had trouble wording it right but I'm not sure how to improve it. The phrasing "the condition returns true" which reads naturally is now technically incorrect as the new types return a Result. However, the underlying condition system that the implementing system turns into does indeed return bool. But talking about the implementation details felt too much. Another possibility is to use another turn of phrase like "the condition holds" or "the condition checks out". I've left "the condition returns true" in the documentation of run_if and the provided methods for now.

I'm perplexed about the examples. In the first one, why not implement the condition directly instead of having a system returning it? Is it from a time of Bevy where you had to implement your conditions that way? In that case maybe that should be updated. And in the second example I'm missing the point entirely. As I stated above, I've only seen conditions used in contexts where they have no input parameter. Here we create a condition with an input parameter (cannot be used by run_if) and we are using it with pipe() which actually doesn't need our system to implement SystemCondition. Both examples are also calling IntoSystem::into_system which should not be encouraged. What am I missing?