It is a valid use case to do things like call wp_session_item_export()
from within the async ready callback of _activate(), and it's not
possible unless the ACTIVATING flag has been cleared first.

To do this, use a GCClosure to wrap the callback and install marshal
guards, which are called before and after the callback, to modify
the flags.

We can now call wp_proxy_request_destroy() on endpoint links and
the WpImplEndpointLink together with the session item that created
it will be cleaned up

+ expose the export transition in the session item class
+ make the export-related flags immutable
+ add an export error flag
+ update and improve documentation

+ replace calling execute_step(..., STEP_ERROR) with rollback
+ implement deactivate internally using rollback

This unifies deactivation steps, which are common between deactivate()
and calling execute_step() with WP_TRANSITION_STEP_ERROR at the
end of a failed activation transition.

+ enable the new log writer on the executables
+ enable structured logging in the tests

* It should be possible to activate/deactivate while an item
  is exported (if the item supports it, but that's a subclass matter)
* It should be possible to deactivate without resetting configuration

To ease the use case where we are only interested in the id
and not the proxy object itself

This allows the implementation to rollback changes, cancel jobs, etc

* introduces API to export session items
* introduces small changes in the WpSiEndpoint & WpSiStream
  interfaces to make it nicer to work with
* ports WpImplEndpoint to use PW_TYPE_INTERFACE_Endpoint
  to export. Depends on:
  https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/246
  (was merged after 0.3.2)

This allows activating a dummy item for unit testing