h264enc: add m_paramLock for parameter access
h264enc: move m_maxOutputBuffer base class

defer m_maxOutputBuffer calculation until it is explicitly required.
 - sometimes parameter are set one by one, we needn't calculate every time
 - video resolution may not set yet
h264enc: insert sps/pps bytestream in yami instead of by driver

add OUTPUT_STREAM_HEADER support which is required for chrome
v4l2vea
insert emulation byte for sps/pps byte stream
v4l2: add v4l2 wrapper for yami

= There are four threads in the wrapper library.
    - Two threads for v4l2 interface:
      one for device pool, one for device operation (deque, enque etc)
    - Two threads are internal worker to drive data input and output respectively.

= Device thread owns yami encoder before input/output thread launch and
  after input/output thread exit.
= encoder->stop() defers to device _close() instead of STREAMOFF ioctl.
= Dynamic encoder parameter change (bitrate/framerate etc) are accepted
  in device operation thread, and executed in input thread, with mutex lock.
= Add mutex locker for encoder (factory) cache,
  avoid thread issue when there are multiple encoders.
= assume initial buffers status are at client side.
test: add v4l2 encode test
test: v4l2encode use encodehelp.h for command line parameters
vaapidisplay: add drm backend support

1. client and yami shares the same display when it provides both native
   display (x11 Display or drm fd) and display type in setNativeDisplay().
   client owns the native display
2. when client set native display type only, yami will create a native
   display and owns it.
3. when client doesn't set any native display, or set display type to
   NATIVE_DISPLAY_AUTO; yami will try to open a x11 display first. if fail,
   drm display will try next

4. A x11 display is compatible to drm display, while not reverse.
   it means, when there is a VADisplay created from x11 display,
   yami will not create a new display when drm display is requested,
   simplely reuse the VADisplay.