Match report-many-errors for APIs and unit tests

[kurtbrose]

This is something we've discussed before, but for unit tests and APIs it's very convenient to keep going and find as many errors as possible rather than stopping on the first error.

Some of the challenges with this:

• how to print a mulit-stack
• how to resume execution after failing one match

Data-stack error reporting is really oriented towards only reporting a single error (this could be addressed by either printing them sequentially, or printing up to the last-common-spec and then printing the branch for each exception separately).

I'm imagining Match objects will have a kwarg "multi-error" or something. This will cause GlomErrors to be caught and execution to resume.  A challenge with this is how to resume execution. Probably this means making the error stack a read/write data structure rather than write only. So that participating glom handlers will be able to "find their place" in the error stack when asked to resume. (The most important is that dict handlers know how to resume execution on the next key, and that list handlers know how to resume execution on the next item of the list.)

The algorithm for resuming execution would be something like this:

Find the leaf-most spec which knows how to resume execution; replace the spec with a version that is resuming from that spot.

[kurtbrose]

Actually, we don't really need to resume -- the handlers could be adjusted.

def glom():
   for child in child_specs:
      try:
          glom(child)
      except GlomError as exc:
         if not scope[MULTIERROR]:
              raise
         errors.append(exc)
   if errors:
      raise MultiError(errors)

[kurtbrose]

Then we just need a MultiError that's able to capture the scope for each of it's sub-errors, and the data stack machinery needs to know what to do with a MultiError to print it nicely.