The proxy API is the one that we would like to expose for applications
and the other API is used internally when implementing modules or
factories.
The current pw_core object is really a context for all objects so
name it that way. It also makes it possible to rename pw_core_proxy
to pw_proxy later.
Implement the local-v4l2 example with a core-proxy connected to
a local instance. We can export and instantiate objects and
link nodes and ports without having to touch the implementations.
Always create a local server without any socket. We can use this
to create clients that connect locally (in-process), such as
the cli or any app that wants to create a local pipeline.
Also disconnect filters.
Ignore multiple destroy calls. This can happen when the protocol
destroys the core-proxy and some implementation cleanup code
does the same. The cleanup code can't reliably know about this
cleanup.
Remove the core_proxy from objects so that it doesn't try to use it
when it's being destroyed.
We need to recheck the core_proxy because it might have been removed
in the destroy signal.
The pw_remote object is really a wrapper around the pw_core_proxy.
The events it emits are also available in the core proxy and are
generally awkward to use.
With some clever new pw_core_proxy_* methods and a pw_core_connect
to create the core_proxy, we can convert all code away from pw_remote.
This is a first step in this conversion, using the pw_remote behind
the scenes. It leaks into some places because it really needs to become
its own struct in a next step.
Let the core load a set of default modules.
Add a key to control what default set to load, falling back to a
reasonable set. Make the daemon not load any set and rely on the
config script to load modules.
