Restorer does really restore shared memory (including page
contents restore) only on master process, while all other
processes do open such memory area via map_files/ procfs entry
so that we might have a situation when shared VMA is present
in some particular core-%d.img file but it's not listed in
collected shmems array and find_shmem_by_pid will return NULL.
This is perfectly fine, be ready for that.

Another issue is that shared memory might look like

CR_FD_SHMEM: /home/cyrill/projects/kernel/crtools/shmem-2641.img
----------------------------------------
0x7f2200775000-0x7f2200776000 id 19664
0x7f2200776000-0x7f2200777000 id 19663
----------------------------------------

So vma area is [x;y) range and we should distinguish two
shmem lookup cases

 - one when we search for page in shmem area
 - second when we lookup shmem area in collected ranges

They both have a different lookup conditions so single
find_shmem splitted into two helpers find_shmem and
find_shmem_page as appropriate.

This patch finally fixes the three process asynchronious
shared memory updates test-case.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>