[dev][platform-bus] Clean-up and simplify platform bus protocol:

- Remove "flags" parameter from pbus_device_add().
Now platform devices can only be started in new devhosts.

- Add new API pbus_protocol_device_add(), for binding drivers that implement
platform bus protocols like GPIO and I2C_IMPL.
pbus_protocol_device_add() is equivalent to pbus_device_add(PDEV_ADD_PBUS_DEVHOST)
followed by pbus_wait_protocol().

- Remove pbus_wait_protocol(). pbus_protocol_device_add() does the wait for you automatically.

- Rename pbus_set_protocol() to pbus_register_protocol()

These changes will hopefully make the platform bus protocol easier
to understand and use.
I found two places where people accidentally using PDEV_ADD_PBUS_DEVHOST
inappropriately (probably copy & paste errors), which resulted in
the entire network stack and storage stack running in the platform bus devhost.
Hopefully this change will make it impossible for mistakes like that to happen again.

While doing this I also noticed that the gauss nand driver and vim2 ethernet driver
were running in the platform bus devhost. This change fixes that.

Also removed some remnants of the pbus_device_enable() API, which has been removed previously.

TEST: boot up on qemu, VIM2, gauss and astro and verified platform devices all start up properly

Change-Id: I580269bc6f53a63348ba8ab580259b1ba56dd393

[pdev] Fix RpcGetBti bug

RpcGetBti now returns the BTI for the correct device.
Previously the root device's own BTIs were being returned.

TEST: Added test to the qemu test driver and verified that devices
always get the BTIs intended for them.

Change-Id: Ic1563e16a3956dbeeb4caf5224c737fc3c24ab4d

[dev][platform-bus] Provide platform bus resources platform device children

Currently the platform bus allows creating a list of platform devices,
each running in a separate devhost.
These devices are provided by the bus with various resources
(MMIO buffers, interrupt handles, GPIOs, I2C channels, etc).
However we have use cases where a platform device may have child devices
that also need resources from the platform bus.

This change allows children of platform devices to access platform bus resources.
To do this, the board driver can pass a list of child devices via the pbus_dev_t
structure passed via pbus_device_add(). These children can also have children,
allowing for a tree of platform devices in the same devhost, rather than just one.
To facilitate this, a platform device must use a new platform device protocol
pdev_device_add() to create the child device rather than calling the DDK
device_add() directly.
The behavior of pdev_device_add() is the same as device_add(), except it inserts
a layer between the parent and child device to allow device_get_protocol()
to return protocols that are implemented by the platform bus
(for example, ZX_PROTOCOL_PLATFORM_DEV, ZX_PROTOCOL_GPIO, etc.)
This allows the children of of platform devices to also be platform devices,
while simultaneously allowing access to the protocol(s) implemented by the
parent device.

This change also adds four drivers to the qemu build to test this new functionality.
The qemu-bus board driver adds a platform device called "parent".
"parent" then creates a child device called "child-1", which in turn has
two children called "child-2" and "child-3".
All of these devices are platform devices and all four of the corresponding drivers
test to make sure that they can access the platform device protocol and map
their own unique MMIO regions.

TEST: manual testing on qemu, vim2 and gauss

Change-Id: Iaa4cd2afb06512dd0a9f9e06ca91c84c348e352f