Catch warnings and messages

[wlandau]

Suggested by @krlmlr, also by @fmichonneau in richfitz/remake#177. For drake, I think a good solution will:

1. Print out warnings and messages to the console when the targets are actually building instead of waiting until the very end.
2. Store the warnings and messages alongside errors in a new "logs" subspace. (Subspaces are condensed versions of storr namespaces that help prevent Huge number of files in .drake/keys .drake/data #154.) Errors are processed and cached here. I suspect ordinary exception handling around the call to one_try() would catch warnings.
3. Register the warnings properly so that they show up if the user calls warnings() after make().
4. Add a new type argument to diagnose() that could be "error", "warning", or "message", depending on the kind of build log the user wants. I am open to suggestions for better names. type could be more specific, and diagnose() could be generalized to a drake_build_log() at that point.

Edit: to do:

• Make diagnose() report errors, warnings, messages, etc.
• Update vignettes and other documentation that references diagnose().
• Test that warnings and messages are printed out at the right times.
• Test that target values, errors, and entire build logs are stored properly.
• Run full battery of long package checks.

[wlandau]

We could also do some restructuring here to help the manual scheduler avoid requiring its workers to access the cache. Most of it will be in run.R and build.R. As @krlmlr mentioned, this could help with Digital Ocean-based caches.

[wlandau]

If we do not want remote processes to write to the cache (#236), then we may have to wait for future to make it possible: futureverse/future#25.

[wlandau]

Echoing @krlmlr's comment in richfitz/remake#177, a complete solution would have drake_build() return an rmonad object. #236 needs something like this, so #227 and #237 rely on it too. Learning rmonad is very high on my priority list.

[wlandau]

FYI: exception handling in rmonad.

[wlandau]

More thoughts: warnings and errors would naturally constitute part of the running meta list (metadata on targets). It will be simpler to load it with drake_meta() like all the other metadata.

[wlandau]

Update: I am optimistic about being able to push a fix today or tomorrow. Rather than jumping to fancy data structures, the expedient thing turned out to be just to add more stuff to the existing metadata. The main change that users will notice is the diagnose() function. Rather than just the error log, diagnose() will print a list that also contains any warnings, messages, and other context of the build.

[wlandau]

Fixed via #248. Tougher than I expected, but it really helps get the internals ready for the next issues.

[krlmlr]

Thanks for looking into it! I'm really eager to try this out, but might take a while.