Draft: Support success return value in @with_signature functions

From dg1d/test/dg1dTests/src/README_TESTS_FAIL.md and formatted:

I implemented the Success tag for return arguments for the @with_signature macro. The @with_signature tests already pass. The issue now is that Riemann solver tests (actually just calls) don't pass, because we adding the success return value now messes things up with broadcasting and argument destruction.

E.g. lax_friedrich_flux likes to call speeds(...) for both sides,

  vl, vr = speed(args_lhs, equation), speed(args_rhs, equation)
  fl, fr = flux(args_lhs, equation), flux(args_rhs, equation)

The correct version of the above would be

  (success_vl, vl), (success_vr, vr) = speed(args_lhs, equation), speed(args_rhs, equation)
  (success_fl, fl), (success_fr, fr) = flux(args_lhs, equation), flux(args_rhs, equation)

which makes it quite verbose and inconvinient. Imagine nested multiple @with_signature calls would at some point add also overhead for the success checks. Not sure if we can live with this by saying that if you call the functions you should always be prepared for unexpected behavior and thus check the success. So far we never did and we seemingly did not have problems.

A more simpler approach to the problem would be to check for validity of results produced by a call to a signature function after the whole computation is done. E.g. if compute_something outputs results into u, v then after the call we can check those arrays. Assuming everything goes well and success is true and u,v are ok and the arrays are of length N. Checking the returned success value for each point will involve N if checks, provided the returned success value indicates validity for both of u, v. The first to fail would immediately stop the loop and one would be able to start with the recovering strategy. Not sure what performance implications this extra return value has. If we were to only check validity after the broadcasted call finished, we will then have to do N checks for each variable, so in this case 2 N. Furthermore, we would have to wait for the whole broadcasting event to finish before we can then check and only then start with the rescue mission. However, I would assume that performance of the loop can only be better in this case since we have one return value less to care about and we don't have to do if checks in the loop.

A thrid approach would be to use a global as a failure indicator that can be set from within every function and later be checked after the loop is done (or perhaps also within the loop). This way we don't have to deal with multiple return values and the validity check after the loop is simple. The drawback is that we introduce coupling.