The comments promised that when using the argumentless constructors of
ZBTxRequest, Tx16Request or Tx64Request, setting the address and payload
would be sufficient to get a working request object. However, this
leaves the transmit options and broadcast radius options uninitialized.
If a request object is allocated globally, these will just end up as 0,
but if allocated on the stack, they can get random values.

For the ZBTxRequest, it is not entirely clear if the 16-bit address
should be explicitly set in this case, so this adds initialization just
in case.

This allows calling these functions directly as well, without having to
bother with casting the Print* to uintptr_t. E.g. you could do something
like:

	Serial.println(F("Unknown message received"));
	printResponse(response, Serial);

Now that these callbacks can also be called directly, printing
"XXXResponse received" can be confusing, since it might not necessarily
be printing a response that was just received.

Previously, the userdata parameter was used as-is, interpreted as a
Print*. If no userdata was supplied when registering the callback, NULL
is passed, resulting an invalid method lookup and a call to a random
piece of memory (often resulting in a lockup).

By checking for this, forgetting to pass userdata will not lockup, but
also not show any error message (since there is no obvious place to
print it to...). If an invalid pointer is passed, things will still
break, of course.

Since the documentation lists them in hex, this makes it easier to look
them up.

Previously, they were passed as normal references. Adding const does not
change the code in any way, but allows passing temporary objects as
well, so you can do:

    req.setAddress64(XBeeAddress64(0, 0xffff));

Or even just:

    req.setAddress64(0x0013A20012345678);