Fix: application SIGBUS when starting in parallel with sessiond

There is a race between application startup and sessiond startup, where there
is an intermediate state where applications can SIGBUS if they see a zero-sized
shm, if the shm has been created, but not ftruncated yet.

On the sessiond side, we need to ensure that the shared memory is writeable by
applications as long as its size is 0, which allow applications to perform
ftruncate and extend its size.

On the UST side, another commit needs to ensure that UST can read the shared
memory file descriptor with a read() system call before they try accessing it
through a memory map (which triggers the SIGBUS if the access goes beyond the
file size)

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: David Goulet <dgoulet@efficios.com>