[process-launcher] Add a process launching binary

This binary exposes a FIDL process launching service. Nothing currently
runs the process.

Change-Id: I8b60a5ba40ec3f4f406855c53f59e8c178122047

[fidl] Move public fidl headers to match naming convention

The fidl library provides headers intended for general use, so the
include path should be spelled <lib/fidl/foo.h> as per
https://fuchsia.googlesource.com/docs/+/master/development/languages/c-cpp/naming.md.
This moves the headers into the proper location and updates includes to
match.

Change-Id: I9db162c3fd40170d63730bc9b7079c7e7e950982

[fidl] Fix alignment in canned fidl structs

This change makes it clear that all fidl message objects should be
8-byte aligned. For most types this did not matter, but for very short
messages (for instance, with just an int32 or a handle) it could make
a difference.

Change-Id: I6fd093ef5205342f62c01719c37c492ad9c20463

[fidl] Factor MessageBuffer out of MessageBuilder

Turns out the memory management of MessageBuffer is useful on the
receiving side as well.

Change-Id: I37d12c489c16f872e9e12afdd675043f1513aa63

[fidl] Add MessageBuilder, which owns the message memory

MessageBuilder is a utility class that makes it easy to build up
messages. Clients that wish to manage memory more precisely should use
Builder and Message separately.

Change-Id: Ia2f664a5d3404bcb224bf58d473dc2edbfef2edb

[fidl] Add fidl::Message data structure

The fidl::Message data structure holds both the byte and the handle part
of a FIDL message and knows how to encode and decode messages in place.
The fidl::Message also knows about the message header and its various
fields.

This CL also moves the C++-related headers into a cpp directory to make
it easier to see which parts of the library are related to the C++
bindings and which are useful from C.

Change-Id: I7031d1b3d9a76b911f7e9de9c3f5aa33a0f700f8

[fidl] Add fidl::String

This patch starts to introduce the C++ FIDL types. These types are views
into the underlying C types that are used by the encode and decode
functions. For decoding, these views are ultimately on the underlying
message buffer, similar to the C types. For encoding, the underlying C
types are stored in a builder and manipulated through the C++ views.

Change-Id: I21b8e2be687c2cfed57d395898e31e3d16bc9961