Handle JSON func values

[zachbadgett]

Leave func handling up to the formatter.

[zachbadgett]

In regards to #832 and #642; no need to clutter our entry with more fields. Let the formatter decide how the field types are handled and replace invalid values with a message.

[dgsb]

Hello @zachbadgett, thanks for your contribution, but I'm not sure if it's better to handle that at the formatter level rather than the Entry level.
We have another set of issues/pr (#365,#151,#207) related to fields for which it makes more sense to implement them at Entry level. I'd rather rationalize all this future work at entry level

[zachbadgett]

IMO, which types to support would best to be left to the formatter. If a user wants to implement a custom formatter and wants to support grabbing details from a custom function in their application then they can.

Either way, I believe you should either move all normalization to the entry (which includes the error to string) or keep it all on the formatter.

[dgsb]

IMO It's kind of different, an error can be stringified. The fact that the json formatter can't is an implementation detail of the json formatter.
While I'm not sure it does not make sense to stringify a function even if the TextFormatter can do it.

[zachbadgett]

Kind of a silly example if someone really wanted to get information on a func: https://play.golang.org/p/zJiQT7AF-ni
I do understand your point about if a func can really be "stringified", the thing I was trying to get at is an entry should be type agnostic, let the formatters worry about which type to support.