timecodestamper: Add scale property

• videotimecode: Replace a G_GINT64_CONSTANT with GST_USECOND
  A minor readability improvement.

• videotimecode: Improve gst_video_time_code_frames_since_daily_jam

  • Use guint64 throughout to reduce the number of casts.
  • Support 119.88 FPS drop frame codes. These were considered valid but not actually handled.
  • When not in drop frame mode, scale using the actual instead of the "normalized" framerate in order to minimize error.
  • For frames longer than a second, round up.

• videotimecode: Improve gst_video_time_code_increment_frame

  • Use guint64 throughout to reduce the number of casts.
  • Use gst_video_time_code_frames_since_daily_jam instead of duplicating the math.
  • Support 119.88 FPS drop frame codes. These were considered valid but not actually handled.
  • Refactor the drop frame code to make it more comprehensible, with less intransparent variable names. The calculation should be the same.
  • When not in drop frame mode, scale using the actual instead of the "normalized" framerate in order to minimize error.

• timecodestamper: Use g_clear_pointer more

• timecodestamper: More refactoring

  • Add a report_tc_update function to handle most of the debug messages about time code updates.
  • Flatten one else { if () {} else {} } into an else if () {} else {}.
  • Use an GstVideoTimeCode * in the RTC code to simplify the code.
  • Use GstVideoTimeDiff and GST_STIME_FORMAT.

• timecodestamper: Fix update_timecode_framerate
  The existing implementation seemed confused about the FPS values.

  It interpreted the old timecode according to the element's FPS (from the last caps event) instead of the timecode's own config. This happened to be correct most of the time.

  It also created the new timecode using that same FPS and then added frames according to the FPS from the arguments, resulting in a timecode not appropriate for the new FPS.

  We shouldn't look at the element's FPS at all. We just need the FPS from the old timecode's config and the new FPS from the arguments to convert elapsed frames to elapsed time and back.

  Don't do anything if the timecode appears to be unset. This behavior shouldn't be restricted to LTC. If it happens to be some timecode that doesn't count frames but just seconds, we don't need to do any converting anyway.

• timecodestamper: Support drop frame timecodes with 119.88 FPS

• timecodestamper: Add scale property
  If set to true, it will scale an incoming timecode of a potentially different framerate than our current one (e.g. if we change frame rates upstream of the timecodestamper).

  For auto_resync, it will make sure that there's not more than 1 frame of difference between upstream and framerate-scaled timecode.