Added a single snapshot time for GetResponse

[ashu-ciena]

The data collected for each individual path in the notification, may carry a different timestamp from other paths. In that case, there is no single view of the complete data for the list of paths in the GetRequest. From a target's perspective the collection for a Subscribe request and a Get request is identical and only the mode of transport of those notification is different. The individual notification gives the timestamp of the collected data of the relevant path in a distributed environment. The target waits for all the individual collections to complete, pack it into a single Get response and send it. With this change, we introduce a timestamp for the entire snapshot, attached when the collection is complete for all the paths and the packet is ready to be sent to the client.

[ashu-ciena]

In the absence of the proposed changes, the below 2 requirements are contradictory to each other.

3.3.2 The GetResponse Message
The GetResponse message consists of:

notification - a set of Notification messages, as defined in [Section 2.1](https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#21-reusable-notification-message-format). The target MUST generate a Notification message for each path specified in the client's GetRequest, and hence MUST NOT collapse data from multiple paths into a single Notification within the response. _**The timestamp field of the Notification message MUST be set to the time at which the target's snapshot of the relevant path was taken.**_
extension - a repeated field used to carry gNMI extensions, as per the description in [Section 2.8](https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#28-extensions-to-gnmi).
3.3.3 Considerations for using Get
The Get RPC is intended for clients to retrieve relatively small sets of data as complete objects, for example a part of the configuration. Such requests are not expected to put a significant resource burden on the target. Since the target is expected to return the entire snapshot in the GetResponse message, Get is not well-suited for retrieving very large data sets, such as the full contents of the routing table, or the entire component inventory. For such operations, the Subscribe RPC is the recommended mechanism, e.g. using the ONCE mode as described in [Section 3.5](https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#35-subscribing-to-telemetry-updates).

_**Another consideration for Get is that the timestamp returned is associated with entire set of data requested, although individual data items may have been sampled by the target at different times.**_ If the client requires higher accuracy for individual data items, the Subscribe RPC is recommended to request a telemetry stream (see [Section 3.5.2](https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#352-sending-telemetry-updates)).

[earies]

I think this is another case where get was not really thought through and discussed widely prior to publish and would suggest raising for discussion in an upcoming OC community call.

I suspect the majority of uses today would be that a single Notification w/ a single Update is delivered with an encoding as json, json_ietf or ascii