ABR transcoding workloads underperform from ill-defined synchronization by input surface

@XinfengZhang, @xhaihao, @onabiull : for your attention

https://github.com/intel/libva/blob/b3be72a5a110880f70626d7c3bed953cdde124b2/va/va.h#L3568

This is the only synchronization function defined in VAAPI. For encoders we use _input_ surface as synchronization object. As a result if we have multiple operations scheduled for the input surface all (encoders) will wait for the completion of last submitted operation. We eventually step into few issues with that:

1. Once first operation completes it actually waits while it can make next operation to start, i.e. we slow down overall processing.
2. Since all threads are waiting on the same vaSyncSurface they will be awaken at the same time and we actually step into thundering herd since they all will suddenly request CPU time.

Please, change VAAPI to eliminate this issue. There are few ways to fix it:

1. The one which https://github.com/intel/media-driver follows is to completely avoid vaSyncSurface for encoders and rely on vaMapBuffer instead. I believe we additionally need to do the following in this case:
1.1. Synchronization via input surface still should be possible for backward compatibility
1.2. Synchronization by vaMapBuffer should be explicitly allowed and noted in the VAAPI documentation
1.3. VAAPI should have capability which can be queried: whether encoder supports synchronization by vaMapBuffer or not
2. Another variant is to have separate call for encoders synchronization. I.e. encoder waits for bitstream to be ready, i.e. vaSyncBuffer(va_bitstream) call should be provided.

The describe issue affects one of the key usage scenario which is ABR transcoding meaning that there is pipeline like:
```
->
->
-> -> encoding
-> -> encoding
```

This issue is also tracked for mediasdk as a consumer of VAAPI: https://github.com/Intel-Media-SDK/MediaSDK/issues/287.