shell: Relayout the containers page

Fixes #1395
Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
base: Provide cockpit.transport.origin property

This is the same as window.location.origin, but we cannot rely
on the latter, since it is not supported by Internet Explorer,
even version 10.

Add documentation and tests.
Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
base: Implement transport.filter() and transport.inject()

These methods allow one to filter incoming messages and inject
outgoing messages. Needed when forwarding WebSocket via another
web frame.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
ws: Cleaner channel-seed suffix

channel-seed should generally be used as a prefix. So add a
separator in to the mix from the very start.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
base: Expose the transport options from the "init" message

This is similar to exposing channel.options. Necessary for forwarding
WebSocket to another iframe.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
base: Channels to the right host provided by the init message

The default-host is now carried by the init message. We use this
to determine the default "host" field in channels.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
base: Send cockpit protocol via parent frame where possible

Instead of each frame opening up their own websocket, send
messages via the parent frame if possible.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
shell: Don't add our own properties to a frame window.

They get removed when the frame content loads.
shell: Register child windows directly.

Instead of finding them again by name.  This is more direct and it
becomes a internal detail of register_child that it associates peer
information with windows via the name.  (Ideally we would use the
Window object itself as the key in a hashtable...)
shell: Use explicit fallback when transport options are not set yet.

This will cease to happen once the shell looks up the packages before
loading external pages.
base: Don't delay opening of a ParentWebSocket.

Instead, do it immediately when returning to the event loop.
base, shell: Be more careful when forwarding control messages.

The "init" command is never forwarded, and non-broadcast messages in
the control channel are only forwarded to their corresponding peer.

Closes #1400.
bridge: Hold ref during cockpit_channel_ready()

If a callback from cockpit_channel_ready() closes and unrefs the
channel, then we need to keep a reference so we can cleanly
finish and return from the function.

Closes #1410
Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
bridge: Add default arg to cockpit_channel_get_bool_option()

So that we can tell the difference between unset and FALSE.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
bridge: Rename the old dbus code out of the way

So we can implement new stuff with the usual 'cockpit.dbus' and
CockpitDBusJson names.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
 * Keep using dbus-json1 for realm operations
doc: Document and design new dbus-json3 protocol payload

There will be additions later, but this is the meat of the
protocol.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
bridge: Implement a new dbus-json3 protocol payload

This protocol is much simpler than the others. There will be some
additions to it in the future, but at it's core it's about relaying
messages and signals.

We don't have innate object manager support in the bridge, the
javascript code will respond to events and update an object model
there.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
base: Implement a javascript client for new dbus-json3

This implements a simple javascript client for dbus-json3. It has
no proxy support at this time, but that will be added later.

Fixes #1352
Fixes #1355

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
doc: Add documentation for cockpit.dbus and related

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
bridge: Add explicit 'type' support for dbus-json3

You can specify the 'type' of a call, and then no Introspect() will
be needed when calling the method. In addition, the 'type' will be
returned in the reply.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>