Add initial logger integration

[geek]

• Includes @hapi/log plugin and configure using new logger settings.
• logger settings are slightly different than @hapi/log options primarily to simplify usage
• Tested with @hapi/log and logger being enabled and there don't appear to be any conflicts, only that log statements can be output twice since there are 2 loggers.

PR is for initial review, shouldn't be merged until we agree that @hapi/log is 1.0.0 complete.

[kanongil]

Just adding some things I noticed.

Also, I would really like to have a way to change the log level at runtime. That way I can up the log level of running servers to better diagnose intermittent issues.

[kanongil]

Writable does not really support instanceof check. Eg. any stream inherited from Duplex will fail this check, as it inherits from Readable. Stream will be the safe check.

[kanongil]

I would prefer const here. Can be done by assigning default values.

[devinivy]

One thing on my mind is how to reconcile logger with debug, since they overlap quite a bit in functionality. I could imagine this being confusing to those who are unfamiliar with the history here. Additionally, you could configure them both on at the same time, which is not likely to be desired behavior. One way to handle it could be to think of this as expanded functionality of debug, adding to the existing debug config. For example, one way to do it would be to piggy-back on the type option:

const server = Hapi.server({
    debug: {
        // This is the default value: typically users wouldn't explicitly set this to 'debug' (backwards compatible)
        type: 'debug',
        request: ['implementation']
    }
});

const server = Hapi.server({
    debug: {
        // Set the type to 'std' or 'pino' to use the new logging functionality
        type: 'std',
        level: 'notice'
    }
});

Then in a major version of hapi we could (for example) rename debug to logger, drop support for type: 'debug', and change the default type to 'std'. This might also get us thinking about how to migrate existing debug config to logger config, which could result in some feature work on @hapi/log or exposing additional options.

[geek]

I think integrating the log plugin might be the wrong approach. We will be forced to expose different log features through hapi and surface helper methods on the server for things like changing the log level. This is fine, but it also tightly couples the log plugin releases with hapi, which may force unnecessary upgrades on people who already have a logging solution. Also, as @devinivy points out there are some inconsistencies between this and the existing debug options. Instead, I propose that we keep log as a separate plugin that we support and encourage people to use for their logging needs.

Thank you for the review on this PR, but I'm going to close this PR for now as it feels like the wrong approach.