VAAPI Support

@AbAb1l is already working on this.

Since Jan 27, 2020.

Supporting VAAPI accelerated transcoding would allow us to use AMD and Intel QSV hardware. The support for VAAPI can mostly be laid on top of the current nvidia support. Some of the things that should be done:

* Update ffmpeg.go to add VAAPI accel type, and emit the `h264_vaapi` codec and `scale_vaapi` filters as needed

* Add PIX_FMT_VAAPI to init_video_filters

* Deal with the hwupload issue. For SW decode -> GPU rescale+encode, we avoid "wiring up" the GPU within LPMS by taking advantage of the `hwupload_cuda` filter which allows to specify a particular device to upload to:

https://github.com/livepeer/lpms/blob/77a56e05eba3017885e8a395136cf8726b0c65ee/ffmpeg/ffmpeg.go#L90-L94

However, the `device` option does not seem available within the plain `hwupload` filter that VAAPI uses. Our choices here would be to patch the `hwupload` filter to take a similar `device` option, or wire things together within LPMS (in a manner similar to how we wire in the decoder). The former seems much more preferable.

Note that SW decode -> GPU rescale+encode is a fringe case for us right now, but it works for nvidia and it would be nice to have symmetrical VAAPI features (otherwise it is sure to become tech debt).

* Check the logistics of building + running VAAPI-enabled binaries on non-VAAPI hardware. This works fine for nvidia, and I don't expect VAAPI to be much different, but it's something we should check. Also figure out whether it's better to depend on system shared libs (as we do for cuda) or statically link something like Mesa.

* Add unit tests mirroring the Nvidia tests (or even better, parameterizing the existing tests)

This is just from a quick skim of https://github.com/livepeer/lpms/pull/114/files ; probably missing steps and I'm certain things will break along the way.