Enable way for resources and dsc.exe to provide verbose/debug information

[SteveL-MSFT]

Summary of the new feature / enhancement

Do we need both verbose and debug? Maybe start with just verbose.
Have a well defined JSONLINE schema for resources to output verbose information. Do we need to a way to turn on verbose for commands or just have it write it all the time and we throw it away if the user hasn't specified dsc --verbose?
What schema makes sense? Perhaps:

resourceType: <type name of the resource>
name: <friendly name if there are multiple instances of resources in config>
message: <open text>
timestamp: <filled in by dsc.exe>

It probably makes sense that resources only return the verbose message itself and dsc.exe fills in the rest. So an example JSON from a resource going to stderr could look like:

{
  "verbose": "this is my verbose message"
}

[michaeltlombardi]

To be clear, the resource is required to emit to stderr like:

{ "<kind>": "<message>" }

So DSC distinguishes between verbose/debug/error messages, or always verbose as the key? What should DSC do with returned output that is non-JSON? Always treat non-JSON on stderr as error messages, or ignore them?

In the initial contract, are we only expecting/handling single string messages?

[SteveL-MSFT]

dsc.exe already knows if being used interactive (TTY exists) vs automation (redirected stdout) so it can emit verbose messages by default if used interactively, but suppress them if automated and have switches to explicitly control the behavior. Although resources emit JSON, dsc.exe should display them as rendered text.