Fix documentation and examples to show simplified usage

[pepinns]

• fix documentation to show simplified usage
• update example to use new functions

[pepinns]

None of this will work of course until the macros are updated.

[ayourtch]

So, I had time to toy with this a little bit, and I think it is not a very good idea to throw more send/recv functionality into the generated crate, so I will try to get away from it.

The reason is: in the client project using the generated latest-vpp-api, one needs to include vpp-api-transport, in order to open the needed connection.

The moment the client attempts to use a different version of vpp-api-transport that the latest-vpp-api uses, we have a problem due to multiple definitions of the symbols...

Ideally I would like to complely get rid of dependency on transport in the generated API crate, and stuff the send/recv logic into some kind of "behavior" crate.

I think I will try to create a separate crate "vpp-api-message-crc" just to hold the trait (since it will be pretty much static), then reference that crate in both generated API crate and the "behavior" crate.

Now, since the end user will deal with the "behavior" crate as well - looks like we have just moved the same problem there...

So, probably the same trick should be applied to transport: keep the trait definition in the vpp-api-transport, and then have af_unix and shmem implementations in separate crates (again, this should help with modularity, since someone can then write a better version of transports, e.g. with not using the shared library altogether).

[ayourtch]

I will try a modified approach: pull out the message name+crc trait definition into an outside crate as i said, but move the send/recv function into the vpp-api-transport crate. this will solve the dependency problem without creating a zoo of crates.