I have a strong urge to refactor the error accumulation; this
`recover_with` and `return_with` isn’t really pretty, adds quite useless
noise to the code, and prevents easy use of existing combinators like
`List.iter`.

So I propose this:
* We collect error messages and warnings in a mutable reference (a list
  or rope) that we just pass down as argument (inside `env`). This is
  used to collect errors (and warnings), but not for control flow.
  (This simulates the writer monad, without the syntactic overhead).
* The exception no longer carries an argument. This is raised when we
  cannot continue due to an error.
  (This simulates the Maybe monad for computations-that-may-fail.)
* There is a `recover_with` function that catches the Error, and continues
  with a useful default.
* At the end, we report all errors and warnings in the mutable ref. And
  if there are any errors, we abort compilation.
  See `recover_and_report`

Now any use of `error` does not abort futher processing, only
`fatal_error` does.

The code in `pipeline.ml` is maybe not the prettiest yet, but lets first
see if this approach actually works inside `typing.ml`.

and more closely match what we had before

the function gather_field_exp is run thrice; not a good place for a
non-fatal error.

This could be refined to make sure the check happens only once, either
by passing down a flag to exactly one invocation of `gather_field_exp`,
or moving the check to a separate, explicitly used function alltogether.

this means that now also warnings will be reported nicely! Will
hopefully make @paulyoung even happier.

as these are checked elsewhere. Improves the error message.

not sure if it really is better, but not worth arguing about.

in particular, everything around sharable functions,  and duplicate
bindings.

this pulls in #88 and addresses the nit that `typing.mli` should not
mention the `errs` field.

hopefully we can resolve #92 soon, stack traces in the test output are a
PITA (I should probably add a post-proccessing filter that normalizes
the output a bit).

the definiton of messages_result will eventually go into a separate
module