Make UNSET enums' String() return "UNSET"

[wenovus]

Returning this message for UNSET seems rather excessive, as reflected by a user: fmt.Sprintf("out-of-range %s enum value: %v", enumTypeName, val)

Since all UNSET values are currently 0, we can just use this fact to return "UNSET" if they're not found within the enum map.

[github-actions[bot]]

Coverage increased (+0.002%) to 90.73% when pulling a4add04a6abc75c49c2315b9a73056731b2ff9c4 on unset-enum-empty into b9d3c8fbd806ad01181ce6608af8e62fef66d208 on master.

[wenovus]

Actually, I think UNSET might be better, since it might be used for logging. Seeing UNSET is probably better than the empty string.

[robshakir]

There was the intention to make the default value of an enumeration be the 0 value in the case that a default was specified for the leaf -- is that currently not-operational? If so, it would mean that UNSET as a string literal might not be the right thing to return.

[wenovus]

Since TogNMINotifications doesn't use the schema to determine the value to marshal, doesn't it mean that this is not operational? https://github.com/openconfig/ygot/blob/c6ce7e55aa79fe2cdd2f5c655b882b9c98f71fd3/ygot/render.go#L287

If we have a typedef enum used in multiple places, then in order to stream the correct default value, TogNMINotifications necessarily has to get this from the schema metadata.

[wenovus]

#172 confirms that this is not in operation in Go. It is also of dubious operation in proto due to the possibility of re-uses of enum typedefs. I think the question of how we're going to support default values in Go needs to be answered first before the concern raised in this PR can be answered.

[wenovus]

Just clarifying here that this PR is dependent on how #101 and specifically #172 are resolved.