Add Result.all

[chriskrycho]

I didn't add it when we originally added Maybe.all because it wasn't clear what the operation should be for the Err case, but it would be straightforward to add now, and worth doing so that you can have a structure-preserving transformation there. We should decide how to treat that scenario: we don't have a type class like Monoid available, so we can't do something clever like have a specialization over monoids that concatenates them but otherwise just pick the first one. We could special-case that way for something like Array, and/or we could simply allow the user to provide an accumulator-style callback.

[wodeni]

This would be very helpful! Also, I've been using this library for writing semantic checkers and running into cases like this:

const type1: Result<T, CheckerError> = checkerFunction1();
const type2: Result<T, CheckerError> = checkerFunction2();
// If both are successful, need to check if type1.value === type2.value
return type1.match({
    Ok: t1 =>
      type2.match({
        Ok: t2 => t1 === t2 ? ok() : err(checkerError("something went wrong")),
        Err: (e) => err(e),
      }),
    Err: (e) => err(e),
  });

My case seems to require more than ap(), because the "transformation function" returns a Result as well. I tried currying and use andThen, but TS seems to have problems typechecking it. Will Result.all be suitable for this kind of use case? I imagine I can just get a Result<T[], CheckerError> back from Result.all(type1, type2) and then I can safely use andThen to do the equality check.