Avoid using pn_message_id()/pn_message_correlation_id() APIs in examples and bindings

These APIs return a pn_data_t to represent a message id/correlation id which has a very restricted set of possible values. All of which are simple scalars - ulong, uuid, binary and string. There is already a setter/getter API that returns a pn_atom_t which is a much simpler and more efficient representation, so we should use this.

We can make up the small API lack of pn_atom_t by introducing some pn_atom_put/get_ulong/uuid/string/binary APIs. But initially pn_atom_t is easy enough to construct/deconstruct especially with C99 structure initiialisers.