g3dlidarparse: Add PTS and duration timestamp management

[ZiningLi]

Description

This PR adds GStreamer buffer timestamp (PTS and duration) management to the g3dlidarparse element. Previously, output buffers had undefined timestamps, which could cause synchronization issues with other streams and prevent proper playback timing in downstream elements.

Changes:

• Add next_pts field to GstG3DLidarParse structure to track presentation timestamps across frames
• Set buffer PTS starting from 0 and incrementing by 1/frame_rate for each output frame
• Set buffer duration to 1/frame_rate when frame_rate > 0
• Reset next_pts on pipeline lifecycle events (init, stop, EOS, SEGMENT, FLUSH) to ensure correct timestamps after stream resets
• Update documentation to explain timestamp behavior and interaction with stride parameter

Timestamp Behavior:

• When frame_rate > 0: Output buffers receive continuous timestamps (e.g., frame_rate=30 produces PTS: 0s, 0.033s, 0.066s... with duration=0.033s)
• When frame_rate = 0: PTS is set to 0 and duration is GST_CLOCK_TIME_NONE (no rate control)
• With stride > 1: Skipped frames do NOT consume timestamp space, ensuring output maintains the target frame rate

This enables proper synchronization in multi-stream pipelines (e.g., lidar + video) and allows downstream elements to perform time-based operations.

How Has This Been Tested?

GST_DEBUG=identity:5 gst-launch-1.0 -v multifilesrc loop=false location="/home/user/zn/prdlstreamer/dlstreamer/tests/unit_tests/tests_gstgva/test_files/%06d.pcd" start-index=1 caps=application/octet-stream ! g3dlidarparse stride=2 frame-rate=30 !
identity silent=false ! fakesink

Checklist:

• I agree to use the MIT license for my code changes.
• I have not introduced any 3rd party components incompatible with MIT.
• I have not included any company confidential information, trade secret, password or security token.
• I have performed a self-review of my code.