change grpclog to use structured logging

[aybabtme]

I took a stab at changing all the log sites to use structured logging, with a pluggable interface. I didn't want to pull existing implementations (like logrus or go-kit/log) to avoid adding dependencies. There are many places, like in tests, where grpclog was used and I think a better use would be to pass around a testing.TB handle, but I didn't do that change to avoid mixing concerns in 1 PR.

Relates to #289.

I signed the CLA.

[dsymonds]

I'm not keen on this at all. It makes the code significantly harder to read. I understand why one would want this, but I don't think it's worth the cost.

[iamqizhao]

I have the same feeling about the readability and usability. In addition, the PR adds an additional mutex to logging, which is unpleasant.

[aybabtme]

Alrighty then! No worries.

@iamqizhao the stdlib logger has a mutex the same way: https://golang.org/src/log/log.go?s=2250:2542#L38

[aybabtme]

Having structured logging somehow would be really nice. Is there another way you folks would see the concept being used by this project?

[iamqizhao]

Yes, I was wrong (that mutex is NOT "Addtional" one). :-) I somehow thought you use stdlib logger in your implementation, which is not true.

Actually your idea is good but the API is not sound. Probably we can have some better idea such as doing a bit reformating so that it would be easy to convert it to the desirable format in post-processing.

[aybabtme]

@iamqizhao I'm not totally following what you mean with:

so that it would be easy to convert it to the desirable format in post-processing

Mind to elaborate? Are there APIs for structured logging that you'd prefer?

I could perhaps, in another PR, change the many uses of grpclog in tests to use t.Errorf and t.Fatalf, which would reduce the noise we see here. Unless there was a specific reason to use grpclog.Fatal in tests?