bundle2: adds a capabilities attribute on bundler20 This attribute conveys the capabilities supported by the destination of the bundle. It is used to decide which parts to include in the bundle. This is currently a set but will probably be turned into a dictionary to allow capabilities with values.

bundle2: include stderr when capturing handlers output We do not discriminate between stdout and stderr yet. But this will do for now.

ui: pushbuffer can now also capture stderr We need an easy way to capture both stderr and stdout during bundle2 processing of a remote bundle. This changeset adds simple changes to the `ui` class to make this possible. I expect the interface to change in future releases as bundle2 will probably want to distinguish stdout and stderr. The current change will, however, do for now.

bundle2: capture remote stdout while unbundling When a reply is built, the bundle processing will capture the output of each handler and sends it to the client in a dedicated part. As a side effect, this add a "remote: " prefix to destination output on local push. This is considered okay for now as: 1. bundle2 is still experimental, 2. Matt said he could be okay to change output for bundle2, 3. This keeps the implementation simple. This changeset does it for stdout only. stderr will be done in a future changeset.

bundle2: introduce `replycaps` part for on-demand reply The bundle2 processing does not create a bundle2 reply by default anymore. It is only done if the client requests it with a `replycaps` part. This part is called `replycaps` as it will eventually contain data about which bundle2 capabilities are supported by the client. We have to add a flag to the test command to control whether a reply is generated or not.

bundle2: use an official iterparts method to unbundle parts Explicit is better than implicit.