Gracefully handle plugin explosions

[str4d]

If an age plugin meets an exothermic demise, rage should print a prefix message and then the output of the plugin's stderr.

[tv42]

I'm writing a plugin, and wish rage would just let plugin stderr flow through (potentially pipe read + prefix + output). I ended up having to make my plugin use syslog just to develop it effectively.

[str4d]

Given that rage uses stderr to communicate with users, I'm reluctant to overload that for developer communication as well. But I definitely want to make it easier for plugin developers to build plugins.

Something that @FiloSottile suggested on his stream yesterday is a plugin test harness: something that is a thin shim over the client-side protocol that exercises all the weird edge cases. As this would be targeted at developers, it would definitely make sense to pipe everything back through and make it accessible.

[tv42]

For the record, I don't intend to leave the verbose stderr on in actual runnable code. I think this is one of those things that would be self-regulating; if a plugin spams your terminal, you develop a dislike for the plugin and look for a friendlier one.

[str4d]

FYI the next version of rage will output all plugin communications, as well as plugin stderr, to rage's stderr if the AGEDEBUG env variable is set to plugin.

This issue (handling plugin panics gracefully) still needs to be addressed.

[str4d]

#446 adds nicer error handling. Instead of outputting stderr directly, it points plugin developers to AGEDEBUG=plugin for debugging, with a warning that this prints private encryption key material to standard error.