init: handle property messages asynchronously #2

A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property.  This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.

This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties

A previous version of this change was reverted and added locks around
all service operations and allowed the property thread to spawn
services directly.  This was complex due to the fact that this code
was not designed to be multi-threaded.  It was reverted due to
apparent issues during reboot.  This change keeps a queue of processes
pending control messages, which it will then handle in the future.  It
is less flexible but safer.

Bug: 146877356
Bug: 148236233
Bug: 150863651
Bug: 151251827
Test: multiple reboot tests, safely restarting hwservicemanager
Change-Id: Ice773436e85d3bf636bb0a892f3f6002bdf996b6