Bunyan

- Guards on `-c CONDITION` usage to attempt to be more user friendly.
Bogus JS code will result in this:

$ bunyan portal.log -c 'this.req.username==boofoo'
bunyan: error: illegal CONDITION code: SyntaxError: Unexpected token ILLEGAL
CONDITION script:
Object.prototype.TRACE = 10;
Object.prototype.DEBUG = 20;
Object.prototype.INFO = 30;
Object.prototype.WARN = 40;
Object.prototype.ERROR = 50;
Object.prototype.FATAL = 60;
this.req.username==boofoo
Error:
SyntaxError: Unexpected token ILLEGAL
at new Script (vm.js:32:12)
at Function.Script.createScript (vm.js:48:10)
at parseArgv (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:465:27)
at main (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:1252:16)
at Object.<anonymous> (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:1330:3)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)

And all CONDITION scripts will be run against a minimal valid Bunyan
log record to ensure they properly guard against undefined values
(at least as much as can reasonably be checked). For example:

$ bunyan portal.log -c 'this.req.username=="bob"'
bunyan: error: CONDITION code cannot safely filter a minimal Bunyan log record
CONDITION script:
Object.prototype.TRACE = 10;
Object.prototype.DEBUG = 20;
Object.prototype.INFO = 30;
Object.prototype.WARN = 40;
Object.prototype.ERROR = 50;
Object.prototype.FATAL = 60;
this.req.username=="bob"
Minimal Bunyan log record:
{
"v": 0,
"level": 30,
"name": "name",
"hostname": "hostname",
"pid": 123,
"time": 1355514346206,
"msg": "msg"
}
Filter error:
TypeError: Cannot read property 'username' of undefined
at bunyan-condition-0:7:9
at Script.Object.keys.forEach.(anonymous function) [as runInNewContext] (vm.js:41:22)
at parseArgv (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:477:18)
at main (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:1252:16)
at Object.<anonymous> (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:1330:3)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)

A proper way to do that condition would be:

$ bunyan portal.log -c 'this.req && this.req.username=="bob"'

- [issue 59] Clear a possibly interrupted ANSI color code on signal
termination.

- [issue 56] Support `bunyan -p NAME` to dtrace all PIDs matching 'NAME' in
their command and args (using `ps -A -o pid,command | grep NAME` or, on SunOS
`pgrep -lf NAME`). E.g.:

bunyan -p myappname

This is useful for usage of node's [cluster
module](http://nodejs.org/docs/latest/api/all.htmlall_cluster) where you'll
have multiple worker processes.

- Allow `bunyan -p '*'` to capture bunyan dtrace probes from **all** processes.
- issue 55: Add support for `BUNYAN_NO_COLOR` environment variable to
turn off all output coloring. This is still overridden by the `--color`
and `--no-color` options.

- issue 54: Ensure (again, see 0.16.2) that stderr from the dtrace child
process (when using `bunyan -p PID`) gets through. There had been a race
between exiting bunyan and the flushing of the dtrace process' stderr.

- Drop 'trentm-dtrace-provider' fork dep now that
<https://github.com/chrisa/node-dtrace-provider/pull/24> has been resolved.
Back to dtrace-provider.