qtmux: For video with N/1001 framerates use N as timescale instead of centiframes

qtmux: For video with N/1001 framerates use N as timescale instead of centiframes

This is recommended by various specifications for such framerates, while
for integer framerates we continue using centiframes to allow for some
more accuracy.

Using N means that no rounding error accumulates, eventually leading to
outputting a packet with a different duration.

Some tools such as MediaInfo determine that a stream is variable
framerate if any packet has a different duration than the others, and
there is no reason I can see for not using the full 4 bytes of
resolution that the mp4 timescale offers.

Example problematic pipeline:

```
videotestsrc num-buffers=5001 ! video/x-raw,framerate=60000/1001,width=320,height=240 ! \
videoconvert ! x264enc bitrate=80000 speed-preset=1 tune=zerolatency ! h264parse ! \
video/x-h264,profile=high-10 ! mp4mux ! filesink location="result2.mp4"
```

This results in a media file that MediaInfo detects as variable
framerate because the 5000th packet has duration 99 instead of 100.

With this patch, the timescale is 60000 and all packets have duration
1001.

Related issue for context: https://bugzilla.gnome.org/show_bug.cgi?id=769041

Co-authored-by: Sebastian Dröge <sebastian@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3049>