Correct permissions for Android IP configuration directory to prevent failing container start

If we don't assign the unprivileged user as owner the container
will fail to start as the Android services wont be able to write
anything into the created directory hierarchy.

Fix cyclic reference between PlatformPolicy and WindowManager and rework DisplayManager

Correct emugl includes and move to std::{mutex,shared_ptr} where possible

Update build-android.md

Fix build with clang

Fixes building anbox with clang 4.0 -- removes unused declarations,
makes sure a template is visible at first instantiation, makes sure
exception declarations match between headers and implementations
Signed-off-by: NBernhard Rosenkränzer <bero@lindev.ch>

Make dependency on properties-cpp explicit

...so its include files are found even in a non-default location

cmds: session_manager: Provide an option to use any container

"anbox_desktop_armv7a_arm" is already renamed to "anbox_desktop_armv7a_neon".

Improve stability of the AdbMessageProcessor

We can now start the Session Manager in Stand Alone Mode.  This means
that the Container Manager is not required, since the assumption is
that the user will provide their own container.  The issue is that
the container related calls are spread throughout the Session
Manager's code base.  So if we attempt to take an instance of the
Container Client class in one if-ed out area, by the time we reach
the next, it will be out of scope.

One solution is to take the instance of the Container Client class
globally, then only make use of it if it's required.  This works
great if the Container Manager is running in the background.
However, since a connection is made to the Container Manager
during the constructor, if the Container Manager is not running,
the side-effect is the following error:

  Failed to connect to socket /run/anbox-container.socket: Connection refused

To solve this problem we will use a global (actually private to
the Session Manager) pointer which will always be in scope.  It
will only be initialised and used when required though.
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Some features which Anbox offer may be useful to users, but can not
be officially supported.  For example, the recently added Stand-Alone
Mode can be utilised to make use of different types of independent
containers where Anbox does not control the complete life cycle, but
since these types of setups can be widely varying and complex, it
would not be impossible to provide support.  Thus, when running in
these modes, it's important for the user to show knowledge that they
are operating in an experimental way.  This functionality provided
by issuing the --experimental flag when starting the Session Manager.
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Normally Anbox will use the default container provided by the
Anbox Container Manager, but some users may wish to run their
own container.  Here we're adding a --standalone flag which
tells the Session Manager not to interact (configure/start)
the Container Manager.  This allows the user to utilise any
other bespoke container of their choosing.  For instance,
this new feature was tested using a Docker container running
the android.img provided by Anbox.
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Print warning if user starts container manager manually

Use a static IP configuration for Android instead of a full blown DHCP setup

Read host os-release file when running inside the snap