Clearly define how uMessages will be routed between uEntities in-vehicle and off-vehicle

This ticket is in reference to the discussion from the uProtocol meeting on march 6th.

There may be an open problem in the way that messages should get routed between entities in the cloud and entities inside a vehicle.

Assume a client uEntity in the cloud with UURI **cloud/1/1/0/**
and a service uEntity on an ECU in a vehicle with UURI **ecu/3/1/1** on a vehicle identifiable as **VIN123456**

Then there exists currently no way for the cloud based client to send a request to the service with UEID **3** on vehicle **VIN123456**.

Possible solutions:
Two possible solutions are

**Hierarchical authorities:**
The UUID of the service instead becomes akin to **ecu.VIN123456/3/1/1**. The service then becomes uniquely identifiable and the client can send requests to it.
The downside of this approach is that it requires that the cloud based client be aware on which in-vehicle device (i.e. which ECU) the service runs on. This may range from impractical for the client developer all the way to impossible if the vehicle architecture must be kept secret.

**A new routing entity:**
This requires a completely new component (similar to the uStreamer) which acts as a api-gateway into the vehicle. This component itself has a UUID like **VIN123456/2/1/1/** and its job would be to look up the in-vehicle authority for any uEntity that gets requested from off-vehicle. The client would then direct its request at UURI **VIN123456/3/1/1** which gets caught by the gateway. The authority of the service with UEID 3 gets determined and the gateway passes the message on to the inside of the vehicle towards UURI **ecu/3/1/1** (with all of the source UURIs trivially known). The response message would get forwarded in the opposite way and have its _source_ authority altered back from **ecu/3/1/1** to **VIN123456/3/1/1**.
The downside of this approach is that either a whole new component is needed, or that the streamer needs to be expanded to handle this, increasing the complexity of any uProtocol network.

Start with the March 6 uProtocol meeting discussion referenced in the issue, then compare the hierarchical-authority and new-routing-entity proposals, including the possible uStreamer expansion. Done means the project has agreed and clearly documented how off-vehicle requests identify, route to, and return responses from in-vehicle uEntities.

Written by the indexing model from the issue text.