drm_hwcomposer: Implement BI and FB caching

This allows saving for about 2-6% of frame time spending in the HWC API
thread (value depends on CPU maturity).

Framework does not create a new buffer for every frame. Instead in 98%
of cases it sends the same buffers over and over (doing circular
shifting of the swapchain).

We can avoid redundant BufferInfo getting and FrameBuffer importing for
the whole layer.

To do this properly first we have to ensure we're having a deal with the
swapchain, not a set of unique buffers. This procedure internally called
the swap chain reassembling.

After we ensure CLIENT is using swapchain, we can safely store BI and
FB for every chain element and reuse it.

Example for single layer:

Frame # |  Buffer Unique ID |     State
 --     | --                | --
      1 |               301 | Reassembling...
      2 |               302 | Reassembling...
      3 |               303 | Reassembling...
      4 |               301 | Caching... (Chain reassembled!)
      5 |               302 | Caching...
      6 |               303 | Caching...
      7 |               301 | Reusing cached data
      8 |               302 | Reusing cached data
      9 |               303 | Reusing cached data
    ... |               ... | ...................
    999 |               304 | Not in cache, purge the cache.
   1000 |               305 | Reassembling...

Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
2 jobs for fb-cache-using-swapchain in 10 minutes and 29 seconds (queued for 1 second)