Fix potential unsafe access to VCMTimestampMap::data

The access to |_timestampMap| was guarded by a lock but
not the access to the data pointer stored in |_timestampMap|.
There was a potential race condition if new data was added
in VCMGenericDecoder::Decode() while the data pointer
retrieved from _timestampMap.Pop() was being used in
VCMDecodedFrameCallback::Decoded().

This CL moves the storage of data to within |_timestampMap|,
instead of being a pointer so that it's guarded by the same
lock.

Bug: webrtc:11229
Change-Id: I3f2afb568ed724db5719d508a73de402c4531dec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209361
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33374}

modules/video_coding/BUILD.gn

@@ -171,6 +171,7 @@ rtc_library("video_coding") {
     "../../api:sequence_checker",
     "../../api/units:data_rate",
     "../../api/units:time_delta",
+    "../../api/units:timestamp",
     "../../api/video:builtin_video_bitrate_allocator_factory",
     "../../api/video:encoded_frame",
     "../../api/video:encoded_image",