feat(errors): Rework how errors work from the ground up

[iambriccardo]

This PR reworks error handling in the etl crate to make it more library-like. Instead of defining many error types for each module, we now have a single main error type, and we group related errors using ErrorKind, which allows us to statically identify the error category without needing to examine the error in detail.

With this mechanism, we are able to write much cleaner code, with less detailed error information, but still accurate enough to define custom strategies for failure retry policies. This work, specifically, will happen after this PR is merged, as we needed a foundational redesign of the error system before addressing more complex error recovery and handling.

In addition to the new error system, this PR includes:

• More tests with failure injection that assert the new error types.
• Refactors the ReactiveFuture initialization method name to wrap.
• Removes unused dependencies.

Currently, the number of ErrorKind variants is based on what we expect to distinguish when handling errors. This is expected to evolve, as we may need to handle more specific groups of errors in the future, requiring additional ErrorKind variants. However, I did not attempt to define the ideal set of variants in this PR, as it’s not feasible to identify all possibilities without using them in real-world error handling. For now, the system simply propagates errors through.

[imor]

Overall looks good apart from a debuggability concern due to some errors we are suppressing.