Using new C++ bindings over the driver transport

When a protocol has a @transport("Driver") attribute, the protocol operates over the driver transport rather than the zircon channel transport:

library fuchsia.example;

@transport("Driver")
protocol Protocol {
    TwoWay(struct {
        request uint32;
    }) -> (struct {
        response uint32;
    });
};

The driver transport builds on the Fuchsia driver runtime , which has different memory management constraints and a different threading model than with Zircon channels. As such, the FIDL client and server types are different from those found in protocols over Zircon channels, to provide a tailored API.

Most client/server types under the fidl:: namespace will have a counterpart in the fdf:: namespace, that provides the same features but is specialized to the driver runtime. For example, whereas one would write fidl::Client to declare an asynchronous client over the Zircon channel transport, to use the example protocol above one would write fdf::Client<fuchsia_example::Protocol>. The generated FIDL header is of the form #include <fidl/fuchsia.example/cpp/driver/fidl.h>.

Similarly, when using the client and server APIs restricted to wire types, whereas one would write fidl::WireClient to declare an asynchronous client over the Zircon channel transport, to use the example protocol above one would write fdf::WireClient<fuchsia_example::Protocol>. One may include the wire subset header at #include <fidl/fuchsia.example/cpp/driver/wire.h>.

C++ bindings over the driver transport is under iteration. For now the tests may serve as examples of using the bindings.