feat: bubble up the error from aggregate failure

[yordis]

Context

We are getting many of these errors, but we do not have many insights into what exactly happens.
This helps us to assess what is failing.

[fahchen]

Suggested change

	{:error, {:aggregate_execution_failed, reason}}
	{:error, :aggregate_execution_failed, reason}

Returning three elements tuple could be more compatible.

1. the result handles in the next codes can handle these results;
   

   commanded/lib/commanded/commands/dispatcher.ex

   Lines 136 to 146 in 7be1943

   	{:error, error} ->
   	pipeline
   	|> Pipeline.respond({:error, error})
   	|> after_failure(payload)
   	{:error, error, reason} ->
   	pipeline
   	|> Pipeline.assign(:error_reason, reason)
   	|> Pipeline.respond({:error, error})
   	|> after_failure(payload)
   	end

2. by adding new middleware to returning {:error, {:aggregate_execution_failed, reason}}, you can get the reason of a aggregate_execution_failed error from the dispatching result.

(note: I'm not a maintainer, just commenting)

[jvantuyl]

I've always found "three-element tuples" to be more trouble. Often, consuming code wants to bubble up errors. Two-element tuples make that easy to detect. Three-element tuples require the surrounding code to add possibly many different matches. As such, I vastly prefer to have the error "reason" become a tuple (or struct) rather than to change the shape of the return value.

[slashdotdash]

We really need at least one test to demonstrate what this change is doing, verify it works as expected, and to ensure that it cannot be inadvertently broken with any future changes.