minigbm: deal with ArcCodec use case by exposing struct map_info

minigbm: deal with ArcCodec use case by exposing struct map_info

Let's keep a count of how many times a buffer has been locked, since
we have special lock_ycbcr() behavior that returns the offsets and
strides of a YUV buffer when an usage of zero is passed in. This behavior
is used by the ArcCodec. We have to take care not to call drv_bo_unmap
if we didn't map anything.

We also have to expose struct map_info so we can return the address if
we have mapped data, rather than incrementing the drv map count.

Additionally, the gralloc.h says:

"THREADING CONSIDERATIONS
It is legal for several different threads to lock a buffer from
read access, none of the threads are blocked."

This implies recursive locking, which this commit implements.

BUG=b:34419220
TEST=
android.video.cts.VideoEncoderDecoderTest#testAvcGoog0Qual0320x0240

Change-Id: Ibbe7dd5349594117aaaecca9647ad45264448575
Reviewed-on: https://chromium-review.googlesource.com/442835
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>