VSE: Build proxies only for slow movies

Don't build proxy file if movie is already fast enough to seek.
To determine movie performance, check if whole GOP can be decoded
in 50 milliseconds.

This test will ensure consistent performance on wide array of machines.

Downside is at most 50ms delay (per strip) when movie is added.
Ideally another test would be performed to detect whether next GOPs
do have same size or not as it may not be safe to assume that movies
will have consistent gop sizes. Even better would be to find biggest
one within small-ish range from start, and perform this test on it.
such test may add about 10ms of additional delay, but provide even more
consistency.

FFmpeg: Adjust default proxy settings

GOP size and quality are adjusted for h264 codec.

These new values are based on result of benchmark on 9 random files:
https://docs.google.com/spreadsheets/d/1nOyUGjoVWUyhQ2y2lAd8VtFfyaY1wQNGj1krCCNbk7Y/edit?usp=sharing

Reducing quality to 50 reduces proxy filesize by about 2x on average
and has no significant impact on decoding performance.

Increasing GOP size from 2 to 10 also reduces proxy filesize 2x-3x
while scrubbing is only about 8% slower. It is still around 100FPS
with 1920x1080 media.
This is unfortunately about 50% slower than MJPEG, but this can be
improved with `fastdecode` tune applied to libx264 encoder

Quite surprisingly h264 codec presets had little influence on proxy
building performance as well as proxy filesize. So far it looks that
FFmpeg does initialize encoder in different way then Blender.
This applies mot only for presets but for tune and profile libx264
setting.
Once this issue is resolved, performance of proxies may be optimized
further.

Reviewed By: sergey

Differential Revision: https://developer.blender.org/D10897

VSE: Fix crash when building proxy

When video file for strip doesn't exist, building crashes on NULL
dereference.

This check was removed by 04e1feb83051.

VSE: Fix building image proxies

Broken by 04e1feb83051

Caused by accidentaly moving `SEQ_proxy_rebuild_finish` outside of
`if (nseq->type == SEQ_TYPE_MOVIE)` condition in function
`SEQ_proxy_rebuild_context()`.

Fix condition for ffmpeg seek workaround

This condition was in contradiction with comment for function
`ffmpeg_generic_seek_workaround()`.

I have noticed, that formats that seeked well used this workaround.
Problem was that I misunderstood code from `av_seek_frame()` - formats
with `read_seek()` function stil don't use generic seeking method.
This is defined in `seek_frame_internal()`

Fix freezed proxy frames

`ffmpeg_generic_seek_workaround()` applied negative offset for seqrched
packet timestamp, but proxies always start from 0 and timestamp can be
negative.

Limit timestamp value to 0, because `av_seek_frame()` doesn't accept
negative timestamps and returns with error. This prevents seeking from
working correctly.

Cleanup: Fix warnings

Introduced in b128ffd53970

Cleanup: Fix warnings

Introduced in b128ffd53970

Fix build error on windows

Error was caused by using `#if` directive in `PyDoc_STRVAR` macro.

This partially reverts 1e4c35d910e18858c41924f9e27ef8e1070cbd0a

Cleanup: Remove SEQ_CURRENT_BEGIN macro

Use LISTBASE_FOREACH instead.
SEQ_CURRENT_BEGIN did null checks, so now these must be explicit.

Reviewed By: campbellbarton

Differential Revision: https://developer.blender.org/D10823